Re: [orbitcpp-list] to hell with inheritance ;)

[Andreas K. <ak...@ix...>]

On Sun, Mar 05, 2000 at 09:19:21PM +0000, Phil Dawes wrote:
> > something came to my mind just this moment. we cannot use inheritance on
> > the stubs, right? We may single-inherit them from CORBA::Object, but
> > that's about it. If we use virtual inheritance, the compiler will add
> > some thunking data, which will be broken (i.e. non-existent) the very
> > moment we reinterpret_cast a CORBA_Object_struct to be a stub. yet, the
> > spec demands implicit widening, so we need to add cast operators for
> > each and every base class. correct? is there any way around this?
> > 
> 
> I'm probably being thick, but I can't see why we need vtable inheritance
> for the stubs. There's no polymorphism done at the C++ level - all calls
> are just sent (statically linked) to the C stubs, which do epv
> polymorphism themselves (using Elliots shortcircuit classid mechanism).
> Or am I missing something? 
> Hmmm... Maybe I haven't thought everything through: If we do multiple
> inheritance without virtual inheritance, you get multiple copies of
> CORBA::Object. Does that matter?

Think so. Consider the usual A,B,C,D diamond of death. D's got two copies of 
CORBA::Object, assume that C's copy is placed behind B's in memory. Assume 
now you'd call one of the stubs inherited from C. C's CORBA_Object_struct
(from its copy of CORBA::Object) is out somewhere in the plains, whatever 
sits behind the "right" CORBA_Object_struct, so the call will most probably 
go segfault or something like that. Not good. Furthermore, if anyone
calls one of A's stubs, the call needs to be disambiguated. (or else people
will run into compiler errors) I'd say we should make the compiler 
intelligent enough to just stick with single inheritance, and in case of MI
generate all the stuff (cast operators, stubs that reinterpret_cast and forward
the call) to simulate the existence of MI. (so we save all the hassle in the
much more probable case of SI, whereas users of MI incur _some_ overhead.)

Example:

    A
   / \
  B   C
   \ /
    D
    
In this case, the compiler might generate something like: (A,B,C 
straightforward, with inheritance)

class D : B {
  operator C { reinterpret_cast... blah... }
  stub_of_C_1(blah) { reinterpret_cast<C *>(this)->stub_of_C_1(blah); }
  stub_of_C_2(blah) { reinterpret_cast<C *>(this)->stub_of_C_2(blah); }
  ...
  rest of D
};

what do you think?

bye
andy