Re: [gtkmm] Slots from non-Gtk subclasses.

[Nick Huxley <nick anvil com>]

> > > Umm, I think you need virtual base class anytime you derive from two
> > > classes that use the same base class.  The classic "diamond"
> > > inheritance tree shows what happens.
> > >             A       A(1)    A(2)
> > >            / \       \       /
> > >           B   C       B     C
> > >            \ /         \   /
> > >             D            D
> > >
> from Effective C++ page 198, 199:
> 
> [...]
> "Now, it may or may not be true that diamonds are girl's best friend,
> but it is certainly true that a diamond-shaped inheritance hierarchy
> such as this is not very friendly. If you create a hierarchy such as
> this, you are immediatley confronted with the question of whether to
> make A a virtual base class i.e., whether inheritance from A should be
> virtual. In practive, the answer is almost invariably that it should;
> only rarely will you want an object of type D to contain multiple copies
> of the data memebers of A. In recognition of this truth, B and C above
> declare A as a virtual base class.
> 
> Unfortunately, at the time you define B and C, you may not know whether
> any class will decide to inherit from both of them, and in fact you
> shouldn't need to know this in order to define them correctly. As a
> class designer, this puts you in a dreadful quandary. If you do not
> declare A as a virtual base of B and C, a later designer of D may need
> to modify the definitions of B and C in order to use them effectively.
> Frequently, this is unacceptable, often because the definitions of A, B,
> and C are read-only. This would be the case if A, B, and C were a
> library, for example, and D was written by a library client.
> 
> OTH, if you do declare A as a virtual base of B and C, you typically
> impose an addition cost in both space and time on clients of those
> classes. That is because virtual base classes are often implemented as
> pointers to objects, rather than as objects themselves. It goes without
> saying that the layout of objects in memory layout for an object of type
> D with A as a nonvirtual base is typically a contiguous series of memory
> locations, whereas the memory layout for an object of type D with A as a
> virtual base is sometimes a contiguous series of memory locations, two
> of which contain pointers to the memory locations containing the data
> members of the virtual base class:"
> [...]
>

 
> Reading that I again feel unconfident about the multiple inheritance
> "feature" in C++.
> I think it was a good thing that JAVA/C# don't support such an
> ill/misleading feature.
> Just my opinion...
> 

Noboday said that Mulitple inheritance was an easy thing but it can be
very useful in avoiding duplicated code which is a good thing.
At least C++ takes care of a lot of the hidden vptr stuff for you. Trying
doing it manually in C and you'll soon learn to love the keyword virtual.

Part of the reason C++ gets a bad deal is that so many people use
inheritance IS-A when they meant containment HAS-A. That leads to
inheritance heirachies 12 deep etc.

Otherwise we would have a situation where everything would be inherited
from the signal object. How much of a pain is it when you don't have
access to the class as it's from a library but you want to use it with
gtkmm? You'd have to wrap it in a inherited signal object and pass
messages to it. Is that really any easier to maintain? If either of the
classes change you have a potential rewrite where as with multiple
inheritance you don't.

Nick