This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: AW: G++ Bug in finding template instanciation
- To: James dot Kanze at dresdner-bank dot com
- Subject: Re: AW: G++ Bug in finding template instanciation
- From: "Martin v. Loewis" <martin at loewis dot home dot cs dot tu-berlin dot de>
- Date: Wed, 10 May 2000 19:10:42 +0200
- CC: kanze at gabi-soft dot de, gcc-bugs at gcc dot gnu dot org
- References: <E1374E494838D3118F6000805FA78E6201644E3D@ffz00za0.wwz1me.mail.dresdner.net>
> 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 nestednamespecifier of a type that was specified using a
# qualifiedid.
So there is no "specifier-id" in this passage. gcc rejects your code
on the ground of this rule. A qualified-id is
qualifiedid:
::-opt nestednamespecifier template-opt unqualifiedid
:: identifier
:: operatorfunctionid
:: templateid
and a nested-name-specifier is
nestednamespecifier:
classornamespacename :: nestednamespecifier-opt
classornamespacename :: template nestednamespecifier
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
simpletypespecifier:
::-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