"Igor Stepanov" <wazar.leoll...@yahoo.com> wrote in message news:pckdwxwvumenyzbuv...@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.