strange thing with template evaluation

Alexandre Oliva
Mon May 31 21:06:00 GMT 1999

On May 12, 1999, "Edwards, Phil" <> wrote:

> I would have thought that 'auto' would dominate the decision-making
> here, since auto's raison d'etre seems to be resolving variable
> declaration ambiguity.

Yep, I used to expect so too, but some authoritative source at
comp.std.c++ (Stephen Clamage, if my memory serves) explained to me
that the decision on whether a declarator is to be parsed as a
function declaration or an object definition is merely syntactic,
whereas checking whether a particular storage-class-specifier is
present or not would require semantic analysis.  I believe it might
have been possible to allow for `auto' to disambiguate this case, but
the Standard says otherwise, so we have to comply.

> + A simple trick to resolve the ambiguity in favor of an +
> expression is to add extra parentheses around the whole +
> expression: `c1((C2()))'

> Erm.  This gave me a parse error, with and without 'auto' present.
> Now I'm extra-confused...

Damn!  I should have checked.  This indeed triggers the egcs parser
bug, that causes `(C2())' to be parsed as a cast missing the value to
be casted :-(

And the usual work-around is to make it clear for egcs that we want an
expression, not a type, using a literal followed by the sequence
(comma) operator and the actual value you want:

C1<C2> c1((0,C2()));

This is ugly and misleading, but it does work (I've tried! :-)

You could also use

C1<C2> c1 = C2();

but the meaning is slightly different, because copy-construction of a
C1<C2> is involved in this case.

Alexandre Oliva IC-Unicamp, Bra[sz]il
{oliva,Alexandre.Oliva}  aoliva@{,}
*** E-mail about software projects will be forwarded to mailing lists

More information about the Gcc-bugs mailing list