Calypso: Direct and full interfacing to C++

[Elie Morisse via Digitalmars-d-announce]

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";

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.