D object model

[Andrej Mitrovic]

One of the problems with wrapping C++ is wrapping multiple-inheritance
classes. You could simulate these with interfaces, e.g.:

interface IRoot { }
interface IBase1 : IRoot { }
interface IBase2 : IRoot { }
class Base1 : IBase1 { void* cppObj; }
class Base2 : IBase2 { void* cppObj; }
class MIClass : IBase1, IBase2 { void* cppObj; }

Now to define a function that can be called with an object instance of
any class in the tree, you can use:
void foo(IRoot obj) { }

Typically every wrapper D class will have an associated pointer to a
C++ object as a void* field (hence that cppObj field up there). This
is to allow invoking C++ library methods on the underlying C++ object,
e.g.:

class Base1 : IBase1
{
    void* cppObj;
    void invokeMethod(IBase1 objArg)
    {
        extern_c_invokeMethod(this.cppObj, objArg.getCppObj());
    }
}

The above allows invokeMethod to be called with any IBase1-inherited
class (IBase1 or MIClass). Note that changing "IBase1 objArg" to
"Base1 objArg" would mean the method can't be invoked with an MIClass
instance (but it would allow direct access to the .cppObj field).

The problem here is performance. Interfaces don't hold state, so
classes which inherit from interfaces have to implement a special
"getCppObj()" method which returns the cppObj field. That means
retrieving cppObj is a virtual call instead of a simple field lookup.

My question is: I I have the definition of *all* the D classes in the
library (+ I control how they're inherited since they're
autogenerated) is it possible to cheat and retrieve the .cppObj field
from an interface parameter without going through a virtual call?

Obviously this would be implementation-dependent, but remember that
all the wrapper D classes would only hold 1 field (cppObj), so I was
hoping using a hack would be somewhat reliable. Here's one way to
cheat:

http://dpaste.dzfl.pl/fd794170

That trick would only be used for the wrapper classes. What I don't
know is, *under what circumstances does it break*? If I knew for sure
that a certain object layout always guarantees this trick to work,
then I could configure my codegenerator to always generate wrapper
code that would make this trick reliable. It could be a good
performance win.