C++Talk.NET C++ language newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  virtual base class and private constructors Goto page 1, 2  Next          C++Talk.NET Forum Index -> C++ Language (Moderated) View previous topic :: View next topic   Author Message Gianni Mariani Guest Posted: Tue Jan 11, 2005 10:41 am    Post subject: virtual base class and private constructors I posted a proposal based on this issue on comp.std.c++ and earlier on comp.lang.c++. It seems that there is no (valid) citation in the C++ standard that explains why the following code is illegal. class Controller { Controller(); // private don't want anyone to call this public: Controller( int ); // this should be called instead }; class Interface : virtual public Controller { public: virtual void DoThing() = 0; }; class Application : public Interface { public: Application() : Controller( 3 ) { } void DoThing() { // Doing it here ! } }; Three compilers gcc 4.0, comeau 4.3.3 and VC++ 7.3 all produce similar diagnostics : % /gcc/gcc-4.0-20041128-build/bin/g++ -o xx virt_inhr_vcbug.cpp virt_inhr_vcbug.cpp: In constructor ‘Interface::Interface()’: virt_inhr_vcbug.cpp:4: error: ‘controller::controller()’ is private virt_inhr_vcbug.cpp:22: error: within this context In the comp.std.c++ thread, James Kanze believed that the compilers rejected *valid* code. James responsed to Andrew Pinski's post on the GCC bug has been unanswered. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19249 The questions are: a) Is this valid code ? b) If it is not valid code, what considerations are there if the standard was changed to accept such code ? c) How does oe go about making a proposal to the comittee ? [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Jeroen Guest Posted: Wed Jan 12, 2005 9:07 pm    Post subject: Re: virtual base class and private constructors Quote: It seems that there is no (valid) citation in the C++ standard that explains why the following code is illegal. a) Is this valid code ? b) If it is not valid code, what considerations are there if the standard was changed to accept such code ? c) How does oe go about making a proposal to the comittee ? I don't see why this should be valid code. 1) Private members are not accessible to publicly derived classes. 2) When there is no default constructor, the compiler generates one. 3) The constructor of a derived class calls the constructors of all parent classes. 4) When there is no specific constructor of a parent in the initialization list of a derived class, the default constructor of that parent is used. So, in your example, the compiler generates a default constructor for "Interface". This default constructor does not refer to any specific constructor of "Controller", so it wants to call the default constructor. However, this constructor is private, and this hidden. The fact that Interface derives virtually from Controller changes nothing that would suddenly make your example valid. The fact that Application in turn derives from Interface also changes nothing. After all, the error message you quote refers to Interface, not to Application Example: class Controller { private: Controller(); // private don't want anyone to call this public: Controller( int ) {}; // this should be called instead }; class Interface : virtual public Controller { public: Interface() {}; // This doesn't work Interface() : Controller(4) {}; // But this does }; Jeroen [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Joe Guest Posted: Wed Jan 12, 2005 9:12 pm    Post subject: Re: virtual base class and private constructors I can't say whether it's valid or not, but I can see where the default constructor for Interface is going to want to invoke the default constructor for Controller. This is illegal as far a i can see. joe [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Joe Guest Posted: Wed Jan 12, 2005 9:38 pm    Post subject: Re: virtual base class and private constructors To continue on with my previous post. I would probably have constructed this like this: class Controller { Controller(); // private don't want anyone to call this public: Controller( int ); // this should be called instead }; class Interface : virtual public Controller { public: virtual void DoThing() = 0; Interface(int controllerInit) : Controller(controllerInit) {} }; class Application : public Interface { public: Application() : Interface( 3 ) { } void DoThing() { // Doing it here ! } }; An that does work successfully. joe [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Markus Moll Guest Posted: Thu Jan 13, 2005 12:14 pm    Post subject: Re: virtual base class and private constructors Hi Gianni Mariani wrote: Quote: Three compilers gcc 4.0, comeau 4.3.3 and VC++ 7.3 all produce similar diagnostics : % /gcc/gcc-4.0-20041128-build/bin/g++ -o xx virt_inhr_vcbug.cpp virt_inhr_vcbug.cpp: In constructor ‘Interface::Interface()’: virt_inhr_vcbug.cpp:4: error: ‘controller::controller()’ is private virt_inhr_vcbug.cpp:22: error: within this context Hm... I think they shouldn't. Quote: In the comp.std.c++ thread, James Kanze believed that the compilers rejected *valid* code. The standard clearly states that initialization of virtual base class sub-objects is done by the most derived class, i.e. by Application in this example. Unfortunately, it does not say that the generated default constructor must not be used to initialize virtual base classes... Quote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19249 The proposed resolution (don't implicitly define an in-charge default constructor) sounds reasonable. The drawback is that errors are only detected when linking. Quote: The questions are: a) Is this valid code ? I'd say it's not totally clear, but anyway, it should be valid. As to the other questions: No idea... Markus [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top dtmoore Guest Posted: Thu Jan 13, 2005 12:19 pm    Post subject: Re: virtual base class and private constructors 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.. 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 [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Gianni Mariani Guest Posted: Thu Jan 13, 2005 4:37 pm    Post subject: Re: virtual base class and private constructors Jeroen wrote: Quote: It seems that there is no (valid) citation in the C++ standard that explains why the following code is illegal. a) Is this valid code ? b) If it is not valid code, what considerations are there if the standard was changed to accept such code ? c) How does oe go about making a proposal to the comittee ? I don't see why this should be valid code. 1) Private members are not accessible to publicly derived classes. 2) When there is no default constructor, the compiler generates one. 3) The constructor of a derived class calls the constructors of all parent classes. Not when the parent class is inherted virtually and the derived class is abstract. Your 3. can't happen according to the C++ standard. If an implementation does this, it is violating the C++ standard. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Gianni Mariani Guest Posted: Thu Jan 13, 2005 4:37 pm    Post subject: Re: virtual base class and private constructors Joe wrote: Quote: To continue on with my previous post. I would probably have constructed this like this: I'm quite aware of how to avoid the compiler errors. The issue is why do you need to write so much code that could never possibly be executed ? ..... Quote: Interface(int controllerInit) : Controller(controllerInit) {} Controller(controllerInit) is never executed - ever. Requiring to pass parameters to the Interface constructor just to have it ignore them makes no sense. A simpler way to write this code would be: Interface() : Controller(42) {} IMHO, it's either a bug in (all) the compiler implementations or a defect in the standard. G [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top L.Suresh Guest Posted: Thu Jan 13, 2005 5:07 pm    Post subject: Re: virtual base class and private constructors It basically depends on where the class is "used". 12/2 says " The implementation will implicity define them if they are used, as specified in 12.1, 12.4, 12.8" 12.1/7 says "An implicity-declared default constructor for a class is implicitly defined when it is used to create an object of its class type" 3.2/2 says "A default constructor for a class is used by default initialization as specified in 8.5" So, the program is correct till the definition of class Interface is finished because the default constructor is not implicity defined till this point. After that the definition of Application begins. The virtual base (Controller) has to be initialized from the most derived class which is done perfectly. The Interface need not not initialize Controller and so does not need to call the private constructor of the Controller. IMHO, the question about the accessibilty remains. Does the standard mandate that the constructor should be accessible even though it will not be called? If it does not then the code appears valid to me. --lsu [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top kanze@gabi-soft.fr Guest Posted: Thu Jan 13, 2005 9:43 pm    Post subject: Re: virtual base class and private constructors Jeroen wrote: Quote: It seems that there is no (valid) citation in the C++ standard that explains why the following code is illegal. a) Is this valid code ? b) If it is not valid code, what considerations are there if the standard was changed to accept such code ? c) How does oe go about making a proposal to the comittee ? I don't see why this should be valid code. 1) Private members are not accessible to publicly derived classes. 2) When there is no default constructor, the compiler generates one. 3) The constructor of a derived class calls the constructors of all parent classes. Not always. Not in this case, in fact. That's the whole point of the exercise. -- James Kanze GABI Software http://www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34 [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top kanze@gabi-soft.fr Guest Posted: Thu Jan 13, 2005 9:43 pm    Post subject: Re: virtual base class and private constructors dtmoore wrote: Quote: 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.. 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. There's nothing in the standard that says that compilers have to allow for possibilities that aren't real. Either there is a case where Interface is the most derived class, and the constructor used in this instance must call the constructor for the virtual base class, or there is no instance where Interface is the most derived class, and the constructors for Interface must never call the base class constructor. The only difference the fact that Interface is abstract makes is that the compiler knows immediately that Interface will never be a most derived class. But how the compiler knows that Interface is never the most derived class is an implementation detail -- the standard explicitly says that if Interface is never the most derived class, the constructors for Interface may NOT call the base class constructor. And I'm certainly not required to provide any functions which can't possibly be called. I rather suspect that the authors of the standard didn't actually want to require this. Using the CFront technique for implementing hierarchies with virtual inheritance, it would be totally unimplementable. But whether they intended to or not, the did require it, and using the techniques used by Sun CC or g++, it shouldn't be that difficult to implement. Quote: 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? It is pretty trivial to construct a contrived example: class D ; class VB { enum X { x } ; VB( X ) {} friend class D ; } ; struct L : virtual VB {} ; struct R : virtual VB {} ; struct D : L, R { D() : VB( VB: ) {} } ; In practice, I always try to provide a default constructor for anything which can be used as a virtual base. Even if all the default constructor does is output an error message and call abort. Quote: 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? The real reason is that it is "ugly", and that it isn't required by the current standard, even if it is by all compilers I know. It's not a big thing, since there are work-arounds. -- James Kanze GABI Software http://www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34 [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top kanze@gabi-soft.fr Guest Posted: Thu Jan 13, 2005 9:48 pm    Post subject: Re: virtual base class and private constructors Joe wrote: Quote: I can't say whether it's valid or not, but I can see where the default constructor for Interface is going to want to invoke the default constructor for Controller. In the code shown, the constructor for Interface is not allowed to invoke a constructor for Controller. Controller is a virtual base, and Interface is not the most derived class. -- James Kanze GABI Software http://www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34 [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top kanze@gabi-soft.fr Guest Posted: Sat Jan 15, 2005 2:52 am    Post subject: Re: virtual base class and private constructors Gianni Mariani wrote: Quote: Jeroen wrote: It seems that there is no (valid) citation in the C++ standard that explains why the following code is illegal. a) Is this valid code ? b) If it is not valid code, what considerations are there if the standard was changed to accept such code ? c) How does oe go about making a proposal to the comittee ? I don't see why this should be valid code. 1) Private members are not accessible to publicly derived classes. 2) When there is no default constructor, the compiler generates one. 3) The constructor of a derived class calls the constructors of all parent classes. Not when the parent class is inherted virtually and the derived class is abstract. Your 3. can't happen according to the C++ standard. If an implementation does this, it is violating the C++ standard. Just a nit, but the C++ standard doesn't make this dependant on whether it can happen, but on whether it does happen. Obviously, if the class is abstract, it can't happen, and so it doesn't happen. But even if the class wasn't abstract, if the constructor isn't called as the constructor for a most derived class, the standard doesn't allow it to call the constructor for the virtual base class, so the code is legal. -- James Kanze GABI Software http://www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34 [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Dave Moore Guest Posted: Sat Jan 15, 2005 3:03 am    Post subject: Re: virtual base class and private constructors <kanze (AT) gabi-soft (DOT) fr> wrote Quote: 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. There's nothing in the standard that says that compilers have to allow for possibilities that aren't real. Either there is a case where Interface is the most derived class, and the constructor used in this instance must call the constructor for the virtual base class, or there is no instance where Interface is the most derived class, and the constructors for Interface must never call the base class constructor. Ok, I see your point, and so I will ammend my earlier statement to say the following: If Interface is not abstract, it puts a much larger burden on the compiler developers, since they must check the every program to make sure noone ever defined an object of type interface. Quote: The only difference the fact that Interface is abstract makes is that the compiler knows immediately that Interface will never be a most derived class. Exactly .. this is obviously much easier to implement. But wait a minute, I may have been missing the forest for the trees here. Doesn't the fact that Interface uses virtual inheritance basically guarantee that it is intended to be used as a base class, and therefore will never be the most derived class? IOW, is there any valid use of virtual inheritance other than its standard use (i.e. the multiple inheritance diamond)? I have searched this NG and comp.std.c++, and I have not been able to discover one. Note that I am talking about reasonable designs here, and not Machiavellian contortions or other pathological cases. So, assuming that there is no other use for virtual inheritance, why not strengthen the language in the Standard to disallow creation of objects from classes that directly use virtual inheritance? So, in the tree: A / B C / D creation of objects of classes B and C would be explicitly forbidden. IMHO, this would provide a significant clarification over the current situation, provided that it is not too restrictive. Quote: But how the compiler knows that Interface is never the most derived class is an implementation detail -- the standard explicitly says that if Interface is never the most derived class, the constructors for Interface may NOT call the base class constructor. So, does that mean that conforming compilers should issue an error or warning if you supply an initializer for Controller in a constructor for Interface? [snip] Quote: 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? It is pretty trivial to construct a contrived example: class D ; class VB { enum X { x } ; VB( X ) {} friend class D ; } ; struct L : virtual VB {} ; struct R : virtual VB {} ; struct D : L, R { D() : VB( VB: ) {} } ; Ok, so it seems like the current situation is that compilers should be *required* to ignore initializers for virtual base classes under most conditions. Doesn't it make sense to enforce this requirement under *all* conditions? This would be the treatment under the proposed modification to the Standard that I suggested above. Dave Moore [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Thomas Mang Guest Posted: Sun Jan 16, 2005 5:28 am    Post subject: Re: virtual base class and private constructors "Dave Moore" <dtmoore (AT) email (DOT) unc.edu> schrieb im Newsbeitrag news:34plncF4ctd1vU1 (AT) individual (DOT) net... Quote: Exactly .. this is obviously much easier to implement. But wait a minute, I may have been missing the forest for the trees here. Doesn't the fact that Interface uses virtual inheritance basically guarantee that it is intended to be used as a base class, and therefore will never be the most derived class? IOW, is there any valid use of virtual inheritance other than its standard use (i.e. the multiple inheritance diamond)? I have searched this NG and comp.std.c++, and I have not been able to discover one. Note that I am talking about reasonable designs here, and not Machiavellian contortions or other pathological cases. So, assuming that there is no other use for virtual inheritance, why not strengthen the language in the Standard to disallow creation of objects from classes that directly use virtual inheritance? So, in the tree: A / B C / D creation of objects of classes B and C would be explicitly forbidden. IMHO, this would provide a significant clarification over the current situation, provided that it is not too restrictive. You may want to provide only classes B and C in a library, which should be able to be used as stand-alone classes. But to make others derive multiply from both B and C (e.g. D is written outside the library, adding additional functionality) without an ambiguous base class, you derive virtually. Since you do not know if your users take use of B and C alone as provided by you, or write their own class D, B and C are certainly not abstract. Andrew Koenig (?) has suggested to derive virtually from exception classes (don't know if he proposed to make the std-exception classes derive virtually from their base classes), so if one derives multiply from exception classes, the the common base class is unambigous and thus accessible in the exception-handler: #include <iostream> #include <ostream> #include <stdexcept> #include <string> struct all_went_wrong : public std::overflow_error, public std::length_error, public std::invalid_argument { all_went_wrong() : std::overflow_error("Oh dear !!"), std::length_error("Aahhhh!!!"), std::invalid_argument("something i do not dare to post publicly"){} }; int main() { try{ throw all_went_wrong(); } catch (std::exception const &) { std::cout << "If you read this, your compiler is broken...."; } } Thomas [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First         C++Talk.NET Forum Index -> C++ Language (Moderated) All times are GMT Goto page 1, 2  Next Page 1 of 2   Jump to: Select a forum C/C++----------------C LanguageC Language (Moderated)C++ Language (Moderated)C++ language (comp.lang.c++)C++ language, library and standards Non-English C/C++ Newsgroups----------------C++ (German)C++ (French)  You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum Powered by phpBB © 2001, 2006 phpBB Group SEO toolkit © 2004-2006 webmedic.