Calypso: Direct and full interfacing to C++

[Rikki Cattermole via Digitalmars-d-announce]

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?