This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [wwwdocs] Additional C++ entries in changes.html
- From: Gabriel Dos Reis <gdr at integrable-solutions dot net>
- To: "Giovanni Bajo" <giovannibajo at libero dot it>
- Cc: <gcc-patches at gcc dot gnu dot org>
- Date: 06 Feb 2004 05:18:50 +0100
- Subject: Re: [wwwdocs] Additional C++ entries in changes.html
- Organization: Integrable Solutions
- References: <0eb301c3ec5b$6cc49ef0$9cba2997@bagio>
"Giovanni Bajo" <giovannibajo@libero.it> writes:
| + <li>G++ is now <strong>much</strong> more conformant to the ISO/ANSI
I think we're either conformant or not ;-) The "much more" sounds
very marketing-departement-ish.
[...]
| + <li>In templates, all non-dependent names are now looked up and bound
| + at definition time (while parsing the code), instead of later when
| + the template is instantiated. This is known as "two-stage name
| + look-up". For instance:
What is known as two-phase name lookup is this:
* for templates, all non-dependent names are looked up in the
templates contexts of definition (e.g. declarations that are
visible at the point of definition of the templates). And
dependent names are looked up in the scopes associated with the
types of the arguments both in the contexts of definition and
instantiation.
(And actually, we still don't fully implement two-phase name
lookup).
[...]
| + <li>Using a name introduced by a typedef in a friend declaration or in an
| + explicit instantiation is now rejected, as specified by the ISO C++
| + standard.
| + <pre>
| + class A;
| + typedef A B;
| + class C {
| + friend class B; // ERROR! No typedef name here!
| + friend B; // ERROR! friend always needs class/struct/enum
Notice however that this will change in the near future through a DR.
But yes, GCC-3.4.x will reject it as is; bu they will be accepted
again in future releases; kind of flip-flop.
-- Gaby