rlb@polari.UUCP (rlb) (05/23/88)
In Stroustrup's book, section 7.2 of the reference manual contains:
unary-expression:
...
new type-name initializer.opt
...
which implies that you can say things like:
int *x = new int = 47;
However, the more detailed explanation of free store in section 7.2.4 contains
the sentence "An initializer may be supplied for certain class objects". This
sentence seems to imply that an initializer may not be applied for other cases.
I could not immediately find any examples elsewhere that showed that
"initializer" could be other than "( expression-list )" for the "new" operator.
Can anyone point me to such examples or something else in the manual that makes
this clear?
-Ron Burk
{sjs: Can't seem to get a round-trip mail path to you that works...}rlb@polari.UUCP (rlb) (05/23/88)
In article <458@polari.UUCP>, rlb@polari.UUCP (rlb) writes: > In Stroustrup's book, section 7.2 of the reference manual contains: > unary-expression: > ... > new type-name initializer.opt and furthermore, how would something like this bind: int *x = new int = 5 + 6; For 'new' to be treated as an operator with unary binding strength, it looks like the above would have to bind as: int *x = (new int = 5) + 6; which would be a little bizarre; equal sign ceases to be an operator in an expression if a certain unary operator appears to the left of it. On the other hand, if it binds like this: int *x = new int = (5 + 6); then it looks a whole lot more like a primary-expression than a unary op; under what circumstances does its precedence and associativity ever matter? -Ron Burk
turner@sdti.UUCP (Prescott K. Turner) (05/27/88)
In article <458@polari.UUCP> rlb@polari.UUCP (rlb) writes: >In Stroustrup's book, section 7.2 of the reference manual contains: > unary-expression: > ... > new type-name initializer.opt > ... >I could not immediately find any examples elsewhere that showed that >"initializer" could be other than "( expression-list )" for the "new" operator. When I tried some examples out on cfront last year, it accepted only initializers of the form "( expression-list )". The grammar in the book is a simplified guide for programming, and has a number of ambiguities more subtle than those resolved by the precedence of operators. Stroustrup acknowledges the book's inadequacy in defining C++. A real language definition is in the works. -- Prescott K. Turner, Jr. Software Development Technologies, Inc. 375 Dutton Rd., Sudbury, MA 01776 USA (617) 443-5779 UUCP:genrad!mrst!sdti!turner
rlb@polari.UUCP (rlb) (05/30/88)
> ... Stroustrup > acknowledges the book's inadequacy in defining C++. A real language > definition is in the works. > -- > Prescott K. Turner, Jr. > ... That will be nice! In the meantime, however, I must continue to glean what I can from the current manual. Which brings me to the following interesting grammar entry: elaborated-type-specifier: key typedef-name key identifier I find this entirely confusing. The best guess I have is that this is just a plain goof-up. It doesn't seem likely that C++ really intends to allow: struct foo a,b,c; where "foo" has not been seen before. When I go back to section 8.2 in the reference manual to look for elucidation on the meaning of "key identifier", it refers me (indirectly) to the non-terminal "name-declaration". Is this production ("key identifier") completely extraneous and if not, what is it for? -Ron Burk