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