Re: [gtkmm] Bug 116280



On Friday 18 July 2003 2:08 am, Daniel Bausch wrote:

[snip]

> There is possibly another problem:
>
> The standard says that the finally derived class must call the constructors
> of all inherited virtual objects. It's not enough when the constructor of B
> calls the constructor of virtual A, but also the constructors of C, D and E
> must call it. Otherwise A's default constructor will be called regardless
> of the definition in B's constructor.
> This is logical because B's constructor does not know that there are two
> instances of class B. If both would initialize virtual A it could be fatal.
> This makes virtual inheritance a problematic feature, because someone who
> derives from a class has to look up the class tree for virtual objects that
> must be initialized with meaningful values. This also makes clear why it is
> in fact only clever to define virtual inheritance for simple classes, that
> only have a default constructor.
> This is another argument, why virtual inheritance may be difficult to
> introduce in a existing class tree and may break API. It should also be
> clear that it definitely breaks ABI.

I am not entirely sure what you are saying, but if it is that the constructor 
of the virtual base class is called multiple times, then that is wrong.  The 
language rules require the constructor of a virtual base class to be called 
exactly once, from the constructor (or initialisation list) of the most 
derived class virtually inheriting it - to that extent initialisation is 
different from that for non-virtual inheritance (in standard non-virtual 
inheritance only the immediate parent may initialise a child).  No other 
arrangement would be possible, as there is only one virtual base sub-object.

You were probably saying something else, but I am afraid it did not come 
through to me.  If you were saying that virtual inheritance is a pain because 
you have to look through the entire inheritance heirarchy to see if there is 
any virtual base object you need to initialise, then you are right.

Chris.




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]