From: Seungbeom Kim on
tohava wrote:
> On Nov 10, 10:26 am, Seungbeom Kim <musip...(a)bawi.org> wrote:
>> Consider the compiler saw a stream of tokens:
>>
>> sizeof int * * E
>>
>> It could be sizeof(int *) * E, or sizeof(int) * (* E). (Of course,
>> E of an arithmetic type would make only the former case well-formed,
>> and E of a pointer type would make only the latter well-formed, and
>> these two cannot happen at the same time.)
>
> I do not believe this is a problem, since barring the lack of sequence
> points, a compiler can interpret a +++ b (I forgot whether it's a + (+
> +b) or (a++) + b, but you get the point).

That's the "maximal munch rule" for determining tokens; since "++" is
a valid token when "+++ b" is in the input stream, "++" is considered
the next token, and the expression is parsed as (a ++) + b. It's not
the same problem as the OP's, though, because the latter is not about
tokens (lexical analysis) but about parsing (syntax analysis).

Of course, a rule that resolves the ambiguity in the OP's case /could/
have been made (though the maximal munch rule would be too rudimentary
here). Just as 2+3*4 is parsed as 2+(3*4) when it could have been parsed
differently. Or just as sizeof a*b is parsed as (sizeof a)*b instead of
sizeof(a*b). For some reason, the ambiguity has almost been precluded
by requiring parentheses for sizeof(type-id), instead of not requiring
parentheses and resolving ambiguities in other ways.

My point is that an ambiguity is possible without requiring parentheses,
and that even though it could have been resolved by another arbitrary
rule, it's much clearer when parentheses are required. sizeof expression
is rather an exceptional case that doesn't require parentheses, and I
would make them required as well if I designed the language.

--
Seungbeom Kim

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]