strange thing with template evaluation

[Alexandre Oliva]

On May 12, 1999, "Edwards, Phil" <pedwards@ball.com> 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 http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
{oliva,Alexandre.Oliva}@dcc.unicamp.br  aoliva@{acm.org,computer.org}
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
*** E-mail about software projects will be forwarded to mailing lists