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

[Christian Meyer <chrisime uni de>]

Hi!

> > 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
> >
> > If B & C didn't inherit virtually from A, then calling B::foo
> > propagates to A(1)::foo, while calling C::foo propagates to
> > A(2)::foo.  So then you've got two base classes (B & C) whose
> > ancestors (A(1) & A(2)) are easily in inconsistent states.  These
> > bugs cause wierd behavior more often than segfaults, and it's not
> > always clear when debugging why variables became inconsistent.
> 
> A good compiler will catch this bug at compile time. I know gcc 3.2
> catches the bug.

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...

Greetings,
Christian