betterC: new operator

9il ilyayaroshenko at
Tue Nov 24 17:02:27 UTC 2020

On Tuesday, 24 November 2020 at 11:22:30 UTC, Petar Kirov 
[ZombineDev] wrote:
> On Tuesday, 24 November 2020 at 05:40:21 UTC, 9il wrote:
>> On Sunday, 22 November 2020 at 11:54:01 UTC, Dibyendu Majumdar 
>> wrote:
>>> I had assumed that new operator is not available in betterC.
>>> But in following code, it seems the only way to initialize 
>>> the object correctly ... is there another way I am missing? 
>>> How should one cleanup objects?
>>> import core.stdc.stdio : printf;
>>> extern (C++) abstract class A {
>>>     void sayHello();
>>> }
>>> extern (C++) class B : A {
>>>     override void sayHello() {
>>>         printf("hello\n");
>>>     }
>>> }
>>> extern (C) void main() {
>>>     scope b = new B;
>>>     b.sayHello();
>>> }
>> Mir's RC classes doesn't use TypeInfo and DRuntime,
>> can be used from C++
>> and C#
> Nice! However, how do you initialize the vtbl of the extern 
> (C++) class? I briefly had a look and mir.rc.ptr.createRC [1] 
> calls mir.conv.emplace [2], which is a public import of 
> core.lifetime.emplace, which as far as I can see uses typeinfo 
> for that [3]. You also have a custom typeinfo implementation in 
> mir.typeinfo [4], but I didn't see anything regarding 
> initializing the vtbl pointer in there, just about the pointer 
> to the destructor.

`emplace` ref uses type info in compile time. This may not work 
with betterC flag, I don't know. But it is a compile-time 
constant, so TypeInfo isn't required to be generated into 

C++ generates its own vtables. Order of methods should mutch in D 
and C++, the implementation of a method may be either on the D 
side or the C++ side.

Sometimes you may need to force the C++ compiler to generate 
vtable using at least one abstract method.

vtable for extern(C++) classes is independent of TypeInfo class. 
But I am not sure how the D compiler generates them.

BTW, to make this work, it should be really an extern(C++) 
interface or abstract classes. So both C++ and D compilers 
generate vtables. And D has some mangling bugs... but finally we 
have ported a really huge private C++/C#/protobuffer codebase to 
D/C# codebase.

> Anyway, impressive work on making the interoperability between 
> D, C++ and .NET more seamless! As a former C# developer, 
> looks much simpler to use than another marshaling 
> techniques for e.g. C/C++. What is the relation between 
> and autowrap's support for .NET [5]?

They are independent projects.

More information about the Digitalmars-d mailing list