This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: AW: G++ Bug in finding template instanciation


> According to 14.8.2.4/4, there are only two nondeduced contexts.
> The first involves specifier-id, and is obviously (I think)
> irrelevant.

Just to make sure we look at the same text, I have

# The nested­name­specifier of a type that was specified using a
# qualified­id.

So there is no "specifier-id" in this passage. gcc rejects your code
on the ground of this rule. A qualified-id is

qualified­id: 
   ::-opt nested­name­specifier template-opt unqualified­id 
   :: identifier 
   :: operator­function­id 
   :: template­id

and a nested-name-specifier is

nested­name­specifier:
     class­or­namespace­name :: nested­name­specifier-opt
     class­or­namespace­name :: template nested­name­specifier

Re-reading all that, it makes no sense: A nested-name-specifier cannot
be specified using a qualified-id. Instead, if you look at the grammar
for simple-type-specifier, you'll find that it contains the options

simple­type­specifier:
   ::-opt nested-name-specifier-opt type-name
   ::-opt nested-name-specifier template template-id

So what the probably meant was

# The simple-type-specifier of a type was specified using a
# nested-name-specifier

That view is supported by the examples:

# If a type is specified as A<T>::B<T2>, both T and T2 are nondeduced.

So as soon as you have a '::' in a parameter type, template arguments
in that type are not deduced.

> Or should I ask in comp.std.c++: frankly, I don't see how anyone can
> make head or tails out of the template chapter.

Yes, please do. Better yet, submit a defect report.

> Note that if you are right, and this code is illegal, we have a real
> problem in the standard.

I agree that this is a problem, but I can't follow your example.

> However, any such an implementation would run into the same problem.
> Results, you cannot reliably call copy (or any of the other
> algorithms, for that matter) with an iterator from one of the standard
> containers.

Why is that? copy takes an iterator as a template argument; there is
no qualified parameter type in that algorithm (or any other of the
algorithms). There is no problem if the actual parameters have
qualified types - what matters that the formal parameters must not be
qualified.

Regards,
Martin

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]