From: usenet only_tech_talk on
I would try this:

template <class T, unsigned int I>
unsigned int foo()
return T::template bar<I>();


[ See for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: rts on
On Mar 22, 6:04 am, "Johannes Schaub (litb)" <schaub-johan...(a)>
> This fails because when parsing the "foo" template, it's not known whether
> "T::bar" is a template. The Standard says
> That's what they moan about. You fix it by saying
> return T::template bar<I>();

Thanks for that thorough explanation. Another corner of the standardI've
not yet traveled to.

> > Is this valid C++ or a bug in gcc?)
> In that case, it will parse the template successfully, because it has its
> expected expression in the parenthesis pair. This will try to get the
> address of "T::bar" (which is known as a template during instantiation:
> 'T::bar' is a dependent qualified name, and it's looked up during
> instantiation, and then it will resolve to a template). It tries to compare
> it with I. That won't work because the template will miss template
> arguments.
> First i thought EDG is wrong with accepting it, but then i stumbled across
> 14.2/3 which rules:
> "After name lookup (3.4) finds that a name is a template-name, if this name
> is followed by a <, the < is always taken as the beginning of a template-
> argument-list and never as a name followed by the less-than operator."
> This indeed makes EDG be correct and the above code valid, because it forces
> the compiler to delay parsing of the context of that name "T::bar": If it
> finds during instantiation that "T::bar" is a template, the "<I>" is
> considered to be a template-argument-list. If it finds "T::bar" is not a
> template, it will parse as a relational-expression, as it would do without
> that rule.
> However, it could well be that 14.2/3 refers only to the pre-parse
> disambiguation lookup that my very first quote above refers to. In that
> case, EDG would be wrong with accepting the code. First parsing a construct
> as an relational expression, and then parsing it as a template-id during
> isntantiation does not look very logical to me, especially since a simple
> "::template" can solve the entire issue completely.

Are you saying this is an ambiguous case? At first it looked like I might
be filing a bug with gcc, but it sounds like the code could be rejected or
accepted and still be compliant?

[ See for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Pages: 1
Prev: enum as key in a std::map
Next: CRTP