[Issue 5380] Subtyping with "alias this" doesn't mix with regular inheritance

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=5380



--- Comment #2 from Max Samukha <samu...@voliacable.com> 2012-11-28 07:16:16 
PST ---
This one is blocking a design for QtD (and potentially other C++ projects using
single inheritance with interfaces) that should allow at the cost of relatively
small constant overhead to avoid:
1) unnecessary and undesirable allocations or lookups of wrapper objects for
object pointers returned by the C++ code.
2) bloating the library with virtual call dispatchers for objects that are
never inherited in D code.

Very roughly:

// Instead of classes, fat pointers are generated for C++ classes:
struct QObject 
{
    bool isDWrapper;
    void* pointerToCppObject;

    // a virtual
    void foo() {
        if (isDWrapper)
            // dispatch to the D override
        else
            // make static call to C++        
    }

    enum dispatchers = q{
        void foo() {
            // dispatch to C++
        }
    }; 
}

// Library
class Inherit(T)
{
    T ref_;
    alias ref_ this;    
    mixin(T.dispatchers);

    this() { isDWrapper = true; }
}

// User
class MyObject : Inherit!QObject
{
    override void foo()
    {
        ...
        super.foo();
        ...
    }
}

// Some function taking a QObject
void bar(QObject obj)
{
    obj.foo();
}

void main()
{
    // Here is the problem: MyObject is not a subtype of QObject 
    bar(new MyObject);
}

The Inherit template subtypes the struct and provides the implementation of the
overrides dispatching calls to the C++ side. If the user does not inherit from
a Qt class (which will be true for most classes), the overrides are never
compiled into the library. When receiving an object from the C++ side, we do
not need to allocated a wrapper objects, just initialize the fat pointer with
the relevant information.

I am not sure whether the craziness of the above is going to make it into the
project but a prototype I've created does work. 

Now that we can link to 64-bit C++ libraries directly on windows, we *maybe*
could try to use (and improve) extern(C++) interfaces in order to avoid the
complications. I am still not sure what to do with 32-bit Windows and would
rather give a try to the design described.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------