Re: Intentions: cheap virtual inheritance

[Marc Girod <girod at stybba dot ntc dot nokia dot com>]

>>>>> "NM" == Nathan Myers <ncm@cantrip.org> writes:

>> This would incur a penalty for non-users of virtual inheritance, and
>> for this reason it has not been explored so far, or so I guess.

NM> I agree that cheap support for mixins would be a good thing in 
NM> Egcs, but I do not believe that the scheme proposed by Marc has
NM> such a little effect on other programs as he suggests.

Ahum. Did I suggest this? I am well aware it would have a large
impact, probably on every class with a virtual table, using or not
virtual inheritance...

NM> To see this, consider what instructions must be generated to 
NM> gain access to data members of a virtual base subobject.  

NM> The most important virtual base in use in the Standard library is 
NM> the ios<> subobject, which contains the flags and error state used 
NM> in nearly all iostream operations.  In the current ABI, these are 
NM> found through a single extra pointer indirection.  In almost any 
NM> vtbl-based implementation each would require a whole series of 
NM> indirections.

Well, I think it is a symptom of the problem I am after, that this is
almost the only use of virtual inheritance in the standard library!
Moreover, note that it is not virtual mixin inheritance!
In the mixin scheme, bases classes have no data (and no non-default
constructors).

In fact since 86, Stroustrup has steadily advocated to split
interfaces and implementation between base and derived classes, and
this is a dead end unless one uses virtual mixins.

Building software from theoretically composable classes practically
scales poorly, but at least mixins work "on paper" -- I know no
alternative! I admit I cannot make them work as efficiently as plain
C. I think the price is worth it. I'd like to show it.

BTW, ios is a good exemple of something quite non-extensible...

You are right, though: as I consider it, the data would be at a
2-indirection distance, but the bright side would be that this would
be a fixed cost, which would not increase through composition.

NM> If Marc's goal could be achieved without increasing the cost of 
NM> access to members of a single virtual base, then this would be a 
NM> marked improvement to the ABI.  Perhaps making a special case for 
NM> single-virtual-base classes would be sufficient, though such an
NM> approach rarely works out.

I expect to win back in the long range, by supporting component
building.
I have a doubt here that I may misunderstand you. Aren't
underestimating the cost I am incurring by focusing on single virtual
bases? These are infrequent, and the costs would be paid in
non-virtual bases as well --by far more significant!

I'll think at optimizations like that only later...

Best Regards!
Marc

-- 
Marc Girod                Hiomo 5/1          Voice:  +358-9-511 23746
Nokia Telecommunications  P.O. Box 320       Mobile: +358-40-569 7954
NWS/NMS/NMS for Data      00045 NOKIA Group  Fax:    +358-9-511 23580
                          Finland            marc.girod@ntc.nokia.com