public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: "B. James Phillippe" <bryan@terran.org>
To: egcs Mailing List <egcs@cygnus.com>
Subject: problem: foo = new (double *)[i]; (fwd)
Date: Mon, 16 Mar 1998 20:25:00 -0000	[thread overview]
Message-ID: <Pine.LNX.3.96.980316081130.26227A-100000@earth.terran.org> (raw)

Hello,

	I know this is slightly off-topic, but the original poster was
comparing behavior of gcc and the Digital UNIX compiler, and the discussion
that follows brings gcc's behavior for the following code fragment into
question.  egcs works the same way.  Perhaps someone can comment on this?

thanks,
-bp
--
B. James Phillippe <bryan@terran.org>
Linux Software Engineer, WGT Inc.
http://earth.terran.org/~bryan

---------- Forwarded message ----------
Subject: RE: problem: foo = new (double *)[i];
Date: Mon, 16 Mar 1998 07:33:47 -0500
From: Michael M Rubenstein <miker3@ix.netcom.com>
To: "'B. James Phillippe'" <bryan@terran.org>

Either your logic or your text is flawed.  I can't say which.

The [draft] standard makes it clear that this should be parsed as 
(new (double*))[i].  From 5.3.4:

	new-expression:
		::opt new new-placementopt new-type-id new-initializeropt
		::opt new new-placementopt ( type-id ) new-initializeropt

	...
	Parentheses shall not appear in the new-type-id of a new-expression.

Since parentheses are not allowed in the new-type-id, this cannot be 
parsed using the first rule, so the second applies and the type-id 
must be enclosed in parentheses; it must be (double*).  Since [i] 
cannot be a new-initializer, the new-expression is  new (double*), 
which gives a double** result.  [i] can only be a  subscript applied 
to this result.


On Monday, 16 March, 1998 03:22, B. James Phillippe 
[SMTP:bryan@terran.org] wrote:
> On Sun, 15 Mar 1998, Michael Rubenstein wrote:
>
> > >The following does not want to compile under cxx on Dec-Alpha 
but
> > >it
> > >does compile under g++. Is it correct C++?
> > >
> > >#include <iostream.h>
> > >
> > >main()
> > >{
> > > double **foo;
> > > int i = 10;
> > > foo = new (double *)[i];
> > > cout << "Hello world" << endl;
> > >}
> > >
> > >Error that I get under "cxx" on the Dec:
> > >
> > >skeletor@tahoma> cxx -o foo foo.cc
> > >cxx: Error: foo.cc, line 24: a value of type "double *" cannot 
be
> > >assigned to an entity of type "double **"
> > > foo = new (double *)[i];
> > >-----^
> > >1 error detected in the compilation of "foo.cc".
> >
> > Dec is correct.  That is parsed as (new (double*)) [i].  It says
> > to
> > allocate a double* and then subscript it.  new(double*) is a
> > double**
> > and subscripting it gives a double* that cannot be assigned to a
> > double**.
>
> I disagree.  The order of operations in my current C++ text lists
> the []
> subscript operator as having a higher precedence than the new
> operator.
> Since the code in parens is natually going to be given highest
> priority, it
> will flow like this: 1.) a pointer to double, 2.) an array of
> pointer to
> double, 3.) allocate space for an array of pointer to double and
> return a
> pointer to it.  The returned value is thus a pointer to pointer to
> double
> (the first element of an array of pointer to double).  Both gcc/++
> and
> HPUX's c++ compilers compile his code without properly, whereas an
> explicit
> (new (double*))[i] fails with similar error.  I would say that
> DEC's
> compiler is broken.  Or is my logic flawed somehow?
>
> cheers,
> -bp
> --
> B. James Phillippe <bryan@terran.org>
> Linux Software Engineer, WGT Inc.
> http://earth.terran.org/~bryan


                 reply	other threads:[~1998-03-16 20:25 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.3.96.980316081130.26227A-100000@earth.terran.org \
    --to=bryan@terran.org \
    --cc=egcs@cygnus.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).