On 23/12/2014 12:14 p.m., Elie Morisse wrote:
Hi everyone,
I have the pleasure to announce to you all the existence of a modified
LDC able to interface directly to C++ libraries, wiping out the need to
write bindings:
https://github.com/Syniurge/Calypso
It's at a prototype stage, but its C++ support is pretty wide already:
• Global variables
• Functions
• Structs
• Unions (symbol only)
• Enums
• Typedefs
• C++ class creation with the correct calls to ctors (destruction is
disabled for now)
• Virtual function calls
• Static casts between C++ base and derived classes (incl. multiple
inheritance offsets)
• Mapping template implicit and explicit specializations already in
the PCH to DMD ones, no new specialization on the D side yet
• D classes inheriting from C++ ones, including the correct vtable
generation for the C++ part of the class
So what is this sorcery? Let's remind ourselves that this isn't supposed
to be feasible:
Being 100% compatible with C++ means more or less adding a fully
functional C++ compiler front end to D. Anecdotal evidence suggests
that writing such is a minimum of a 10 man-year project, essentially
making a D compiler with such capability unimplementable.
http://dlang.org/cpp_interface.html
Well.. it is :D
Calypso introduces the modmap keyword, as in:
modmap (C++) "cppheader.h";
That really should be a pragma.
pragma(modmap, C++, "cppheader.h");
Since pragma's are the way to instruct the compiler to do something.
to generate with the help of Clang libraries a "virtual" tree of C++
modules. Then after making Clang generate a PCH for all the headers, the
PCH is loaded and classes, structs, enums are placed inside modules
named after them, while global variables and functions are in a special
module named "_". For example:
import (C++) Namespace.SomeClass; // imports Namespace::SomeClass
import (C++) Namespace._; // imports all the global variables and
functions in Namespace
import (C++) _ : myCfunc, myGlobalVar; // importing the global
namespace = bad idea, but selective imports work
Being a prototype, I didn't really pay attention to code conventions or
elegance and instead focused on getting things working.
And being tied to LDC and Clang (I have no idea how feasible a GCC
version would be), it's going to stay like this for some time until I
get feedback from the contributors on how this all should really be
implemented,. For example Calypso introduces "language plugins", to
minimize the amount of code specific to C++ and to make support of
foreign languages cleaner and less intrusive, although it of course
needs numerous hooks here and there in DMD and LDC.
Calypso is still WIP, but it's in pretty good shape and already works in
a lot of test cases (see tests/calypso/), and is almost ready to use for
C++ libraries at least. Since C libraries are in the global namespace,
it's not a convenient replacement yet for bindings until I implement the
Clang module map format. More info this blog post detailing some of the
history behind Calypso:
http://syniurge.blogspot.com/2013/08/calypso-to-mars-first-contact.html
So.. Merry Christmas dear D community? :)
My take on the current talks of "feature freezing" D: the strength of D
is its sophistication. The core reason why D fails to attract more users
isn't the frequent compiler bugs or regressions, but the huge amount of
time needed to get something done because neither equivalent nor
bindings exist for most big and widespread C++ libraries like Qt. All
these talks about making D a more minimalist language won't solve much
and will only result in holding back D, which has the potential to
become a superset of all the good in other system languages, as well as
bringing its own powerful unique features such as metaprogramming done
right.
By removing the main reason why D wasn't a practical choice, this will
hopefully unlock the situation and make D gain momentum as well as
attract more contributors to the compilers to fix bugs and regressions
before releases.
Will you be upstreaming this? Or maintaining this completely yourself?
