------- Additional Comments From gianni at mariani dot ws 2005-01-14 03:00 -------
I request that we reopen this bug in light of some further discussions. From: comp.lang.c++.moderated : Sender: [EMAIL PROTECTED] After reading your code and the discussion in the comp.std.c++ thread: http://groups-beta.google.com/group/comp.std.c++/msg/3f6fda6a03cb5c6a I guess I have to agree with James Kanze that the example code is valid. The relevant passage in the Standard (12.6.2/6) says: " All subobjects representing virtual base classes are initialized by the constructor of the most derived class (1.8). 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 omitted) Since an abstract class can *never* be the most derived type, then it is clear that all mem-initializers for virtual base classes of abstract classes simply do not matter, since they will always be ignored. However, since this point was not explicitly laid out in the standard, I guess it is forgivable for compiler developers to have overlooked it until now. Perhaps it would be a good idea for the next version of the standard to explicitly make a provision for this case? I also think the OP should resubmit the bug to gcc, including the rationales from these NG discussions. One last point, I do not agree (as suggested by James Kanze) that the code would be valid if Interface were not an abstract class. It seems to me that, according to the current Standard, the compiler must allow for the possibility that an Interface object will be created somewhere down the line, and make sure it has the proper initializers for its base classes, virtual or not. As a side note, can someone come up with an example where it is impossible (or at least unreasonably difficult) for the designer of a concrete class to provide valid, albeit potentially irrelevant, initializers for its virtual base classes? I could not, but that certainly doesn't mean it can't be done. For example, in the OP's example, everything would be fine if the code were modified as follows: (leading backquotes added to preserve indenting .. blame Google for eating whitespace) class Interface : public virtual Controller { public: // or protected ` Interface() : Controller(0) {} // ALERT!! initializer will be ` // ignored in derived classes ` // rest of class }; Ok, I can see why this might be considered "ugly", and it certainly should be unnecessary for abstract classes, as I stated above. However is there a reason why it shouldn't be required for concrete classes, as currently mandated by the Standard? Dave Moore -- What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19249
