Fun with extern(C++)
Igor via Digitalmars-d
digitalmars-d at puremagic.com
Tue Jan 26 09:29:39 PST 2016
On Tuesday, 26 January 2016 at 16:25:35 UTC, Benjamin Thaut wrote:
> On Tuesday, 26 January 2016 at 16:13:55 UTC, Manu wrote:
>>
>> Probably, but the layout of the vtable is defined by the
>> interface,
>> and the interface type is always known, so I don't see why
>> there
>> should be any problem. Whether it's extern(C++) or extern(D),
>> the
>> class populating the vtable with functions knows the layout.
>> I think it all comes down to this conversion to Object thing.
>> If an
>> interface must do that, then that's probably an issue without
>> jamming
>> an Object instance in the class somewhere.
>
> For a C++ class the first entry in the vtable is actually the
> first virtual function. (usually the destructor).
>
> For a D class the first entry in the vtable is the classinfo.
> Thus the problem if you derive a D class from a extern(C++)
> base class. I don't see any way to actually fix this, adjusting
> the this pointer won't help. Once you derive a D class from a
> extern(C++) base class it is no longer a fully functional D
> class. For example monitor (e.g. synchronized methods) won't
> work.
Why couldn't D have been designed to extend the C++ class layout
with the vtable at the start and the new stuff at the bottom?
Would that have worked? If so, why not allow for a new class
layout like "extern(C++) class X { }"
More information about the Digitalmars-d
mailing list