Mapping constructors is complicated... Operator overloads are
much worse, they just don't all map.
You have misunderstood me.
I spoke out against the mapping. I spoke only about access.
For example if we automatically generate a binding extern(C++)
interface we can add a special methods to access to operators and
constructors/destructors.
For example:
С++:
class Foo
{
int operator<(const Foo&);
int operator>(const Foo&);
int& operator[](size_t);
Foo();
~Foo();
};
D automatically generated interface:
extern(C++) interface Foo
{
final int __operator_lt(const Foo);
final int __operator_gt(const Foo);
final ref int __operator_index(size_t);
final void __constructor();
final void __destructor();
}
Those operator-access methods shouldn't have operator semantic in
D. If user want to use C++ __operator_lt for compare objects in
D, him cat manually create opCmp method and use __operator_lt in
it. But it is user task. I think, we should only provide access
to operators and constructors methods.
About constructors:
In addition those methods we can add some information methods.
For example size_t __sizeof() method which return size of this
object. After this we can provide some allocate+constructor
functions. For example:
auto foo = cppNewClass!Foo(args);
This template functions perform next actions:
1. Try to find overloaded operator new(). If overloaded new has
been finded then cppNewClass will use it, otherwise cppNewClass
will use default new.
2. Try to find constructor, which can called with specified args.
3. Allocate memory using __sizeof() method.
4. Call constructor over alloated memory.
for pair to cppNewClass can be provided cppDeleteClass function
with same semantic.
This support layer will very simplify interface with C++ code.
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.
Ok. I've created pull request
https://github.com/D-Programming-Language/dmd/pull/2053
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.
I've bumped two old bugzilla issues about extern(C++)
http://d.puremagic.com/issues/show_bug.cgi?id=1687
http://d.puremagic.com/issues/show_bug.cgi?id=4620
Please comment it and close if they are invalid.
