-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
wrote:
> 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