Re: ORBit mail 1 - Multiple-inheritence

[Phil Dawes <philipd parallax co uk>]

David Wragg wrote:
> 
> [...]
> Phil> Implicit upcasting is when you treat a pointer to a derived
> Phil> class as if it were a pointer to a base class without any
> Phil> change to that pointer.
> 
> You are absolutely right that this is a problem with MI, and this one
> has no simple solution (at least, no-one has ever published one, and
> this problem comes up when implementing many OO languages).
> 

Elliot Lee posted a solution on the orbit mailing list, although it's
very expensive in space and initialisation time requirements (On^2 where
n is the number of class implementations):

Each new interface that is registered with the orb is given a unique
array index (handed out sequentially). For each object you simply
dynamically generate a great big vepv containing space for epv pointers
to *every* interface the orb knows about at that point. The class
initialisation function then fills in all the function pointers for the
interfaces that it implements. The stub functions then use the global
interface id to reference the implementation for the required interface.
Because the id is global, both derived and base classes reference the
same position in the vtable.
As I said, it's very expensive in space and doesn't scale too well, but
might be efficient for small-ish numbers of interfaces.

(I hope I've got that right Elliot - it took a while for me to realise
(to my horror ;-) what you were describing)


> In fact, the C mapping doesn't even allow you to represent references
> to derived interfaces as a different type to references to base
> interfaces - all object references have to be of the type
> CORBA_Object. This throws any form of static typing out the window,
> and every C method call stub has to do a test on the type of the
> object. This represents real stupidity on the part of the spec
> authors, as it penalizes many possible ORBs without producing any
> significant benefit for any other ORBs. So IMHO part of the solution
> is to include a separate C mapping which doesn't have the problems of the
> CORBA one.
> 

We might end up needing to do that - I'm worried that if we don't
provide an efficient in-proc implementation for ORBit people will carry
on using proprietary api's for plugins and application extensions in
gnome, and we could miss out on generic scriptability and all the other
benefits of having components adhere to a common standard.


> However, the CORBA C mapping has to be offered as well and for this
> dynamic type checks and conversions are needed in each stub
> function. But these checks can be as cheap as ObjC or Smalltalk method
> calls, or Java interface reference casts, which are commonly
> considered acceptable. For instance, each interface is given an index,
> and each vtable has an associated hash table, i.e.:
> 
>       Object Descriptor
> 
>           vtbl ----------------> conv_tbl -------------> ...
>            .                     methods
>            .                        .
>           vtbl ----\                .
>            .        \
>            .         \
>                       \--------> conv_tbl -------------> ...
>                                  methods
>                                     .
>                                     .
> 
> These hash tables map for interface ids to the offset in the object
> descriptor required to yield an object reference of the interface, or
> a special value saying that conversion is not possible. This is not so
> expensive - it's quite possible that in modern machines the cost of
> hash table lookups (if well implemented) will disappear into the noise
> of caching effects.
> 



I might try some performance tests with the glib hash this weekend.



> >
> > Could you show me what your a_B() stub function looks like?
> 
> ???

Whoops, I meant B_m2().
Doesn't matter now - I was interested in how the base interface stubs
knew how to call the implementation of m2 without an explicit cast. 


> 
> >
> >
> > Also, I don't understand how this works (with reference to the above):
> >
> > /* Produced by IDL compiler: */
> > void C_m2(CORBA_Object a_C, CORBA_Environment *ev)
> > {
> >     void **obj_descr = a_C;
> >
> >     ((void (*)(void))obj_descr[4][0])(obj_descr[6], ev);
> > }
> >
> > Is this meant to be a full implementation of the stub function or just
> > an illustration?
> > Whats the row width of obj_descr? It's declared as a void** so my
> > compiler complains that it doesn't know the length of void* when
> > attempting to build the double-dereference code.
> 
> It's pseudo-C, because this is skirting around the edge of what can be
> expressed in C, so a proper C version requires many many casts. It's
> probably much better for me to describe the required steps, without a
> type system to get in the way. See below.
>  [...]


Sorry, got the wrong end of the stick there... (I even tried to compile
it!)

Cheers,

Phil.

-- 
_______________________________________________________________________
 Phil Dawes                               |   My opinions are my own
 WWW:    err.. temporarily non-existant   |   and nothing to do with
 Email:  philipd@parallax.co.uk           |      my employer.