[Voted into WP at October, 2009 meeting.]
Proposed resolution (July, 2009): Add the indicated text (moved from paragraph 11) to the end
of 11.9.3 [class.base.init] paragraph 7: Change 11.9.3 [class.base.init] paragraph 8 as follows: If a given non-static data member or base class is not named by a
mem-initializer-id (including the case where there is no
mem-initializer-list because the constructor has no
ctor-initializer) and the entity is not a virtual base
class of an abstract class (11.7.4 [class.abstract]), then if the entity is a non-static data member that has a
brace-or-equal-initializer, the entity is initialized as
specified in 9.5 [dcl.init]; otherwise, if the entity is a variant member (11.5 [class.union]), no initialization is performed; otherwise, the entity is default-initialized (9.5 [dcl.init]).
[Note: An abstract class (11.7.4 [class.abstract]) is
never a most derived class, thus its constructors never initialize
virtual base classes, therefore the corresponding
mem-initializers may be omitted. —end note]
After the call to a constructor for class X has
completed... Change 11.9.3 [class.base.init] paragraph 10 as follows: Initialization First, and only for the constructor of the most derived
class Then, direct base classes Then, non-static data members Finally, the compound-statement of the constructor body
is executed. [Note: the declaration order is mandated to ensure that base and
member subobjects are destroyed in the reverse order of
initialization. —end note] Remove all normative text in 11.9.3 [class.base.init] paragraph
11, keeping the example:
...The initialization of each base and member constitutes a
full-expression. Any expression in a mem-initializer is
evaluated as part of the full-expression that performs the
initialization. A mem-initializer where the
mem-initializer-id names a virtual base class is ignored during
execution of a constructor of any class that is not the most derived
class.
shall proceed proceeds in the
following order:
as described below (6.8.2 [intro.object]), virtual base classes shall be
are initialized in the order they appear on a depth-first
left-to-right traversal of the directed acyclic graph of base classes,
where “left-to-right” is the order of appearance of the
base class names in the derived class base-specifier-list.shall be are
initialized in declaration order as they appear in the
base-specifier-list (regardless of the order of the
mem-initializers).shall be
are initialized in the order they were declared in the
class definition (again regardless of the order of the
mem-initializers).
All subobjects representing virtual base classes are initialized
by the constructor of the most derived class (6.8.2 [intro.object]). If the constructor of the most derived class does not
specify a mem-initializer for a virtual base class V ,
then V 's default constructor is called to initialize the
virtual base class subobject. If V does not have an
accessible default constructor, the initialization is ill-formed. A
mem-initializer naming a virtual base class shall be ignored during
execution of the constructor of any class that is not the most derived
class. [Example:...
Must a constructor for an abstract base class provide a
mem-initializer for each virtual base class from which it is
directly or indirectly derived? Since the initialization of
virtual base classes is performed by the most-derived class, and
since an abstract base class can never be the most-derived class,
there would seem to be no reason to require constructors for
abstract base classes to initialize virtual base classes. It is not clear from the Standard whether there actually is
such a requirement or not. The relevant text is found in
11.9.3 [class.base.init] paragraph 6: This paragraph requires only that the most-derived class's
constructor have a mem-initializer for virtual base classes.
Should the silence be construed as permission for constructors
of classes that are not the most-derived to omit such
mem-initializers?
Christopher Lester, on comp.std.c++, March 19, 2004:
If any of you reading this posting happen to be members of the above
working group, I would like to encourage you to review the suggestion
contained therein, as it seems to me that the final tenor of the
submission is both (a) correct (the silence of the standard DOES
mandate the omission) and (b) describes what most users would
intuitively expect and desire from the C++ language as well. The suggestion is to make it clearer that constructors for abstract
base classes should not be required to provide initialisers for any
virtual base classes they contain (as only the most-derived class has
the job of initialising virtual base classes, and an abstract base
class cannot possibly be a most-derived class). For example: I believe that, by not expressly forbidding it, the standard does
(and should!) allow the above code. However, as the standard doesn't
expressly allow it either (have I missed something?) there appears to
be room for misunderstanding. For example, g++ version 3.2.3 (and
maybe other versions as well) rejects the above code with messages
like: Fair enough, the standard is perhaps not clear enough. But it seems
to be a shame that although this issue was first raised in 2000, we
are still living with it today. Note that we can work-around, and persuade g++ to compile the above
by either (a) providing a default constructor A() for A, or (b)
supplying default values for i and j in A(i,j), or (c) replace the
construtors B1() and B2() with the forms shown in the two comments in
the above example. All three of these workarounds may at times be appropriate, but
equally there are other times when all of these workarounds are
particularly bad. (a) and (b) may be very bad if you are trying to
enforce string contracts among objects, while (c) is just barmy (I
mean why did I have to invent random numbers like 5, 6, 7 and 8 just
to get the code to compile?). So to to round up, then, my plea to the working group is:
"at the very least, please make the standard clearer on
this issue, but preferrably make the decision to expressly allow
code that looks something like the above"
All sub-objects representing virtual base classes are initialized by
the constructor of the most derived class (6.8.2 [intro.object]). If the constructor of the most derived class does not
specify a mem-initializer for a virtual base class V ,
then V 's default constructor is called to initialize the virtual
base class subobject. If V does not have an accessible default
constructor, the initialization is ill-formed. A mem-initializer
naming a virtual base class shall be ignored during execution of the
constructor of any class that is not the most derived class.
struct A {
A(const int i, const int j) {};
};
struct B1 : virtual public A {
virtual void moo()=0;
B1() {}; // (1) Look! not "B1() : A(5,6) {};"
};
struct B2 : virtual public A {
virtual void cow()=0;
B2() {}; // (2) Look! not "B2() : A(7,8) {};"
};
struct C : public B1, public B2 {
C() : A(2,3) {};
void moo() {};
void cow() {};
};
int main() {
C c;
return 0;
};
In constructor `B1::B1()':
no matching function for call to `A::A()'
candidates are: A::A(const A&)
A::A(int, int)