On Sunday, 19 May 2013 at 13:56:56 UTC, Daniel Murphy wrote:
"Igor Stepanov" <[email protected]> wrote in message
news:[email protected]...
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?
