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                       ]