C++ constructors, destructors and operator access

Daniel Murphy yebblies at nospamgmail.com
Mon May 20 05:58:09 PDT 2013


"Igor Stepanov" <wazar.leollone at yahoo.com> wrote in message 
news:pckdwxwvumenyzbuvdpv at forum.dlang.org...
> 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).
>

Mapping constructors is complicated...  Do they have the same semantics in 
both languages?  Both on the heap and on the stack?  Eg. how on earth do you 
map a default constructor for a struct?  Same problems with destructors. 
Which allocator do you use for the heap?  etc

Operator overloads are much worse, they just don't all map.  Do we support 
part of the set?  Or add the missing ones to D? eg comparison operators

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

It does?  Is this problem linux only?  I don't see any reason why it would 
be excluded on purpose.

That said, extern(C++) is mostly untested.  There are some truly awful bugs 
lurking if you try to use complicated types/declarations.  This is slowly 
improving. 




More information about the Digitalmars-d mailing list