C++ constructors, destructors and operator access

Igor Stepanov wazar.leollone at yahoo.com
Sun May 19 07:59:18 PDT 2013


On Sunday, 19 May 2013 at 13:56:56 UTC, Daniel Murphy wrote:
> "Igor Stepanov" <wazar.leollone at yahoo.com> wrote in message
> news:wuevxraaffhaaceapqfv at forum.dlang.org...
>> Is this mean, that D functions will _not_ create C++ objects 
>> with new?
>> For example:
>> You have moved parser to D, but you haven't moved expressions 
>> to D yet.
>> And you want to create new Expression object in parser (in D 
>> code), but Expression class defined in C++. What will you do 
>> in this case?
>
> This is not how we're moving it.  The entire frontend will be 
> moved in one
> go, there will never be a need to create a C++ class from D.
>
> That said, the glue layer will remain in C++ and will need to 
> create
> instances of classes defined in D.  The current glue layer 
> calls 43
> different constructors.
>
> I don't have a solution for this yet, but it will probably be:
> a) Extend D to allow creating classes with constructors 
> callable from C++
> b) Create/generate factory functions for each class new'd in 
> the glue layer
> c) Remove all class allocations from the glue layer
>
> I'm leaning towards b, or maybe c, and I think you should too.

Yes, language shouldn't be modified for the sake of one goal.
But do you think, that calling C++ constructors from D is not 
typical task? I sure, that we must get a common way to bind C++ 
classes to D. No templates, no exceptions. But operators and 
constructors/destructors is needed. It may be special tool, that 
eat C++ header and return D file + C++ glue file. This util 
should transform all fields and constructors to D final methods 
for extern(C++) interface.
In addition to this tool we can make a D binding layer, which 
simplify typical operations such as creating C++ objects using 
::operator new() (or class operator new() if in exists) and 
destroying with  operator delete() (local or global).

By the way: Why D disallow static __gshared C++ variables in 
classes? This is a principled feature (if yes: why?) or omission?


More information about the Digitalmars-d mailing list