Re: Parse error

[Joe Buck <Joe dot Buck at synopsys dot com>]

Matt Austern writes:

> Consider the following file:
> struct my_class {
>    my_class(int);
>    void abcd();
> };
> 
> int foo();
> 
> void bar() {
>    my_class(foo()).abcd();
> }
> 
> The compiler rejects bar() with a parse error.  What's going on is
> that it doesn't recognize "my_class(foo()).abcd()" as an expression-
> statement; it thinks that it's an ill-formed declaration.  (Because,
> of course, it treats "my_class(foo()); as a well-formed declaration.)
> 
> I don't think this is correct.

I don't either, but this is not an easily solved problem.

> Section 6.8 [stmt.ambig] of the C++
> Standard says that if an expression-statement with a function-
> style conversion is indistinguishable from a declaration where
> the declarator begins with a "(", it is parsed as a declaration.
> However, that's not the case here.  That statement cannot be
> parsed as a declaration.  The note section 6.8, paragraph 1,
> says that sometimes the whole statement must be examined
> to determine how to resolve the ambiguity; you can't just look
> at the first couple of tokens.

Things like this are known problems (at least to g++ old-timers and
developers).  The current bison-based parser plus special kludgery (mainly
consisting of a special lookahead pass that sits between the lexer and the
parser) doesn't make it easy to handle such things.  Some cases of
ambiguity between declarations and conversions are handled successfully,
but others are not.

> Is there an alternative analysis that says that the compiler's
> behavior is correct?

I don't think that anyone claims that the current behavior is correct.

I think the long-term answer is that Mark Mitchell and others are working
on a new C++ parser that will make such things easier to handle.  Mark,
here's a test case for you. :-)