Topic: Use of multiply inherited nested types ambiguous?
Author: doug@monet.ads.com (Doug Morgan)
Date: Mon, 4 Apr 1994 19:28:14 GMT Raw View
In article <jpcauvin-310394180644@slip-2-84.ots.utexas.edu> jpcauvin@bongo.cc.utexas.edu (Roger L. Cauvin) writes:
>In article <DOUG.94Mar29161313@monet.ads.com>, doug@monet.ads.com (Doug Morgan) wrote:
>
>> class Common {};
>> class Base : public Common {};
>> class Thing : public Base, public Common {};
>>
>> Given a Thing, how can one access the Common subobject (not the
>> Common::Base subobject)? Example:
Oops, Base::Common.
>>
>> Thing t;
>> (Common&)t; \\ Error: ambiguous.
>
>It is possible to reference the Common subobject unambiguously if you use
>virtual base classes:
>
>class Command {};
>class Base : public virtual Common{};
>class Thing : public virtual Base, public Common {};
I think this cure may be worse than the illness (which is mostly
imaginary anyway). I first noticed the possibility of the problem
when exploring the consequences of removing virtual base classes from
a class library.
Other workarounds are 1) the problem never comes up in "real" code and
2) put a dummy class between Common and Thing, as in:
class Common {};
class Base : public Common {};
class CommonDummy : public Common {};
class Thing : public Base, public CommonDummy {};
Thing t;
(CommonDummy::Common&)t;
Author: jpcauvin@bongo.cc.utexas.edu (Roger L. Cauvin)
Date: 5 Apr 1994 22:45:49 GMT Raw View
In article <DOUG.94Apr4112814@monet.ads.com>, doug@monet.ads.com (Doug
Morgan) wrote:
<robust virtual base class solution deleted>
> I think this cure may be worse than the illness (which is mostly
> imaginary anyway). I first noticed the possibility of the problem
> when exploring the consequences of removing virtual base classes from
> a class library.
>
> Other workarounds are 1) the problem never comes up in "real" code and
> 2) put a dummy class between Common and Thing, as in:
>
> class Common {};
> class Base : public Common {};
> class CommonDummy : public Common {};
> class Thing : public Base, public CommonDummy {};
>
> Thing t;
> (CommonDummy::Common&)t;
1. The cast in the last line of code above will not compile.
2. Two copies of the Common class exist. This duplication, whether or not
it
leads to compiler or run-time errors, is a design flaw. The use of
virtual
base classes solves all of these problems.
Roger
Author: doug@monet.ads.com (Doug Morgan)
Date: Mon, 11 Apr 1994 18:06:06 GMT Raw View
In article <jpcauvin-050494174129@slip-2-13.ots.utexas.edu> jpcauvin@bongo.cc.utexas.edu (Roger L. Cauvin) writes:
>
>In article <DOUG.94Apr4112814@monet.ads.com>, doug@monet.ads.com (Doug
>Morgan) wrote:
>
><robust virtual base class solution deleted>
>
>> I think this cure may be worse than the illness (which is mostly
>> imaginary anyway). I first noticed the possibility of the problem
>> when exploring the consequences of removing virtual base classes from
>> a class library.
>>
>> Other workarounds are 1) the problem never comes up in "real" code and
>> 2) put a dummy class between Common and Thing, as in:
>>
>> class Common {};
>> class Base : public Common {};
>> class CommonDummy : public Common {};
>> class Thing : public Base, public CommonDummy {};
>>
>> Thing t;
>> (CommonDummy::Common&)t;
>
>1. The cast in the last line of code above will not compile.
Sorry, that should have read:
(Common&)(CommonDummy&)t;
>2. Two copies of the Common class exist. This duplication, whether
>or not it leads to compiler or run-time errors, is a design flaw.
Fortunately, the duplication needn't lead to compiler or run-time
errors. Rather than a design flaw, the duplication is more an
exercise in avoiding virtual base classes.
>The use of virtual base classes solves all of these problems.
They also force you to deal with increased storage overhead per
instance, slower casting up, impossibility of casting down (without
built-in or user built RTTI), slower object construction/destruction,
slower virtual function execution, and necessity of including
mem-initializers for all virtual bases (direct and indirect) on each
constructor.
>Roger
Doug
--------------------------------------------------------------------
Doug Morgan, doug@ads.com, (415) 960-7444
Advanced Decision Systems (a division of Booz-Allen & Hamilton Inc.)
1500 Plymouth St., Mountain View, CA 94043-1230
--------------------------------------------------------------------