-betterC and extern(C++) classes

Yuxuan Shui via Digitalmars-d digitalmars-d at puremagic.com
Sun Sep 10 08:12:12 PDT 2017

On Sunday, 10 September 2017 at 14:42:42 UTC, Moritz Maxeiner 
> On Sunday, 10 September 2017 at 14:04:20 UTC, rikki cattermole 
> wrote:
>> On 10/09/2017 2:19 PM, Moritz Maxeiner wrote:
>>> If TypeInfo for extern(C++) classes is removed, couldn't 
>>> final extern(C++) classes without base class and which don't 
>>> implement any interfaces omit the vtable so that the 
>>> following assert holds:
>>> ---
>>> final extern(C++) class Foo {}
>>> static assert (__traits(classInstanceSize, Foo) == 0LU);
>>> ---
>>> The reason I ask is that fairly often I have an abstraction 
>>> that's better suited as a reference type than a value type, 
>>> but doesn't need any runtime polymorphy (or the monitor 
>>> standard classes have). Structs + pointers are the only way I 
>>> know of to avoid the (in this special case) unneeded vtable 
>>> overhead, but it always ends up looking worse to read.
>> We can do it for any class if its final.
> Even final classes can always inherit (potentially already 
> overridden) virtual methods from their parent classes and since 
> all normal D classes inherit from core.object : Object [1], 
> which defines virtual methods (`toString`, `toHash`, `opCmp, 
> and `opEquals`), I don't see how this can be true.

With a final class reference, we always know what function to 
call at compile time (since it can't be inherited). Therefore we 
don't need a vtable.

>> The problem isn't generating the vtable's. But the information 
>> required for casting.
> This applies to normal D classes, but D doesn't support 
> (dynamic) casts for extern(C++) classes, anyway, so this 
> shouldn't be an issue for them.
> [1] 
> https://github.com/somzzz/druntime/blob/74882c8a48dd8a827181e3b89c4f0f205c881ac5/src/object.d#L50

More information about the Digitalmars-d mailing list