Re: C++ multiple inheritance [was Re: [GD-General] Eiffel]

[Jesse J. <jes...@mi...>]

At 11:49 PM -0500 1/2/02, Thatcher Ulrich wrote:
>On Dec 27, 2001 at 03:46 -0800, Jesse Jones wrote:
>>  At 4:56 PM -0500 12/27/01, Thatcher Ulrich wrote:
>  > >On Dec 22, 2001 at 04:30 -0800, Jesse Jones wrote:
>  > I assume you're talking about a smart pointer class that requires
>>  invasive changes to the object it's pointing at. For example, a smart
>>  pointer class that maintains ref counts and requires that the object
>>  have a common reference counted implementation.
>
>Yup, that's what I meant.
>
>>  In general I think it's better to try to come up with a non-invasive
>>  design.
>
>I'm curious to know more; can you explain, or point me at a reference?

For the case above you can put the ref count inside the smart pointer 
class. The only tricky bit is that the smart pointer objects have to 
share the count, but you can handle this by making the first smart 
pointer object instantiated allocate the count on the heap. When a 
smart pointer is copied it copies the ref count ptr and adjusts the 
ref counts. This is a bit slower because of the one extra allocation, 
but it's awfully nice to be able to easily pass around ref-counted 
pointers for arbitrary types.

>  > However I have dealt with problems like this. For example, I used to
>>  have an Invariant class that allowed for DbC-style invariant checks.
>>  The class had a virtual Invariant method and a counter that was
>>  incremented when entering a public method and decremented when
>>  exiting a public method. But mixins still wanted to call the
>>  invariant so what I did was dynamic_cast the mixin this pointer to an
>>  Invariant* and call the Invariant method if the result wasn't NULL.
>
>I've been pondering this.  I think dynamic_cast has a couple of
>problems for this usage.  For one thing, it's slower than a virtual
>base class lookup.

Big deal. As long as you're aware of the overhead and don't do 
anything silly it should be fine.

>I realize that you're advocating a hierarchy that looks like this:
>
>B
>|
>C D A
>  \|/
>   E
>
>But I don't think there's a good way to enforce that.

Nope, and even if you're careful and rigorously distinguish between 
main-line and mixin classes it's still possible to accidentally mix 
in the same class twice into an inheritance hierarchy. However in 
practice I haven't found this too be much of a problem and this 
approach neatly sidesteps all of the subtleties and ugliness 
associated with virtual inheritance.

   -- Jesse