Inheritance Puzzler

[kk_oop]

I'm having an inheritance problem. My mom says she just won't leave me
her Three Stooges DVD collection when she's gone. Okay, just a bit of
OO levity. Here's the real problem:

We have AbsBase1, AbsDerived1, AbsBase2, ConcreteBase, and
ConcreteDerived.

The following inheritance hierarchy applies (arrows point to base
classes):

AbsBase1<---AbsBase2<---ConcreteDerived

ConcreteBase<---ConcreteDerived

Note that ConcreteDerived is the same class type on both lines.

AbsBase1 has an abstract method called doThis(). ConcreteBase
implements a virtual doThis(). ConcreteDerived has no doThis() method.
This causes a compiler error saying that ConcreteDerived needs to
implement doThis(). I was surprised it didn't compile, since I figured
that ConcreteBase's doThis() implementation would serve as the
ConcreteDerived implementation. So we want to do something like this:

Does this compiler error seem correct? If so, what do I need to do to
get this design to work? Namely, what do I need to do to be able to
get doThis() to run polymorphically through AbsBase1 given an object of
type ConcreteDerived?

AbsBase1* myAbsBase1 = new ConcreteDerived();
myAbsBase1->doThis();

Thanks for any input!

Ken

[Noah Roberts]

The following inheritance hierarchy applies (arrows point to base
classes):

AbsBase1<---AbsBase2<---ConcreteDerived

ConcreteBase<---ConcreteDerived

Note that ConcreteDerived is the same class type on both lines.

AbsBase1 has an abstract method called doThis(). ConcreteBase
implements a virtual doThis(). ConcreteDerived has no doThis() method.
This causes a compiler error saying that ConcreteDerived needs to
implement doThis(). I was surprised it didn't compile, since I figured
that ConcreteBase's doThis() implementation would serve as the
ConcreteDerived implementation.

Read this:

http://www.informit.com/content/imag...er/alexch1.pdf

[mlimber]

kk****@yahoo.com wrote:

We have AbsBase1, AbsDerived1, AbsBase2, ConcreteBase, and
ConcreteDerived.

The following inheritance hierarchy applies (arrows point to base
classes):

AbsBase1<---AbsBase2<---ConcreteDerived

ConcreteBase<---ConcreteDerived

Note that ConcreteDerived is the same class type on both lines.

Do you mean ConcreteDerived uses multiple inheritance like this:

struct ConcreteDerived : AbsBase2, ConcreteBase { ... };

Perhaps one of these FAQs will answer your question:

http://www.parashift.com/c++-faq-lit...html#faq-25.10

http://www.parashift.com/c++-faq-lit....html#faq-24.3

If not, please give us more details (code?) on the relationship between
the classes.

Cheers! --M

[Carlos Martinez]

For polimorphism, C++ implementations use vtables.
Virtual methods in different classes in the same hierarchy, occupy the
same slot in vtable.
I think implementation of vtable is compiler-dependant, but usually
would be something like:

vtable for AbsBase1 (pointers or references)

slot 1 virtual method1
slot 2 virtual method2
slot ... your doThis (naturally virtual)
slot n virtual methodn

vtable for AbsBase2:

slots of AbsBase1
slots of AbsBase2 (those that aren't in AbsBase1)

vtable for ConcreteBase:

slot 1 virtual method1
slot 2 virtual method2
slot ... your doThis (naturally virtual)
slot n virtual methodn

vtable for ConcreteDerived:

slots of AbsBase2 (of course includes AbsBase1 slots)
slots of ConcreteBase

thus there're 2 slots for doThis, because there are 2 diferent sections.
One for each hierarchy.
In vtable for type ConcreteDerived, only assign a value to doThis slot
in ConcreteBase vtable section in Concrete derived but not the
corresponding slot in slots proceding from AbsBase1 hierarchy.
When you are using a pointer to AbsBase1, you are using a view of
ConcreteDerived class, corresponding to AbsBase1 section in the vtable,
thus you hasn't doThis.

kk****@yahoo.com wrote:

I'm having an inheritance problem. My mom says she just won't leave me
her Three Stooges DVD collection when she's gone. Okay, just a bit of
OO levity. Here's the real problem:

We have AbsBase1, AbsDerived1, AbsBase2, ConcreteBase, and
ConcreteDerived.

The following inheritance hierarchy applies (arrows point to base
classes):

AbsBase1<---AbsBase2<---ConcreteDerived

ConcreteBase<---ConcreteDerived

Note that ConcreteDerived is the same class type on both lines.

AbsBase1 has an abstract method called doThis(). ConcreteBase
implements a virtual doThis(). ConcreteDerived has no doThis() method.
This causes a compiler error saying that ConcreteDerived needs to
implement doThis(). I was surprised it didn't compile, since I figured
that ConcreteBase's doThis() implementation would serve as the
ConcreteDerived implementation. So we want to do something like this:

Does this compiler error seem correct? If so, what do I need to do to
get this design to work? Namely, what do I need to do to be able to
get doThis() to run polymorphically through AbsBase1 given an object of
type ConcreteDerived?

AbsBase1* myAbsBase1 = new ConcreteDerived();
myAbsBase1->doThis();

Thanks for any input!

Ken

[Gavin Deane]

Please don't top-post.

Carlos Martinez wrote:

For polimorphism, C++ implementations use vtables.
That's one way. It's about the only way I've come across. But it's not
mandatory.
Virtual methods in different classes in the same hierarchy, occupy the
same slot in vtable.
I think implementation of vtable is compiler-dependant, but usually
would be something like:

*If* an implementation uses vtables, the way it uses them is indeed
compiler-dependent. So you should be aware that if you take advantage
of the particular way your compiler handles vtable, you are making your
code highly non-portable.

Gavin Deane

[Carlos Martinez]

Gavin Deane wrote:

Please don't top-post.

Carlos Martinez wrote:

For polimorphism, C++ implementations use vtables.

That's one way. It's about the only way I've come across. But it's not
mandatory.

Virtual methods in different classes in the same hierarchy, occupy the
same slot in vtable.
I think implementation of vtable is compiler-dependant, but usually
would be something like:

*If* an implementation uses vtables, the way it uses them is indeed
compiler-dependent. So you should be aware that if you take advantage
of the particular way your compiler handles vtable, you are making your
code highly non-portable.

Yes, I know is implementation-dependant. What I want is to put an
example for understanding the problem, and why virtual methods with the
same name in differente hierarchies aren't interchangeables.

I thought that explaining that implementation, was a good maner for
understanding why doesn't compilers recognize the method doThis.

I'm not an expert and may be, I'm not clear enough explainig it.

Gavin Deane