C++ constructors, destructors and operator access

[Igor Stepanov]

> 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.