Topic: core issue 147 and mem-initializer-id, qualified-id, injected-class-name's
Author: "msalters" <Michiel.Salters@logicacmg.com>
Date: Fri, 4 Feb 2005 22:02:19 CST Raw View
Hi,
3.4.3.1 had been changed a lot since 1998, to deal with
repetitions of class names like
struct B {
B();
}
B::B() { ; }
B::B b;
The problem with the second form is that the class-name B is
injected in its own scope. So, B::B looked up B in its own
scope and indeed found a class B. This was fixed by making
the injected name B formally an injected-class-name, and
modifying 3.4.3.1 so that B::B names the ctor. N1655 modifies
it again, to restrict it to places where "the constructor is
an acceptable lookup result".
Now, one of the advantages of the pre-N1655 form was that
it also outlawed funny stuff like
struct D_notok {
D_notok() : B::B::B() { }
};
while it probably does allow
struct D_ok {
int B;
D_ok() : B(1), B::B() { }
};
The reason is that I think that B::B( ) is a member-initializer-id
which isn't a qualified-id, but in B::B::B( ) the nested-name-specifier
is B::B:: and that is a qualified-id. It's illegal, of course because
it names the constructor in a nested-name-specifier.
Now, with N1655 the wording in 3.4.3.1 no longer applies to such
cases and B::B::B( ) is again legal. B::B:: is just a nested name
specifier, where the second B is the injected-class-name.
Do I read it correctly? Is it intended?
Regards,
Michiel Salters
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]