Re: DIP 1016--ref T accepts r-values--Formal Assessment
On Thursday, 24 January 2019 at 07:18:58 UTC, Mike Parker wrote: https://github.com/dlang/DIPs/blob/master/DIPs/rejected/DIP1016.md Here, the DIP Author clearly expresses two reasons why a programmer may choose to declare a function to accept ref arguments. The Language Maintainers see this as the core of the proposal and would expect the distinction between the two cases to be maintained throughout. However, this proposal does not maintain the distinction and instead conflates the two cases. The Language Maintainers insist that any proposal allowing ref parameters to accept rvalue references must clearly define how functions which make use of ref for side effects will not accept rvalues. Sorry, but that's just irrelevant / missing the point. On Thursday, 24 January 2019 at 09:31:41 UTC, Manu wrote: Hooray! Who didn't see that coming 10 years off! I didn't see that coming and I'm deeply frustrated and disappointed by this review and rejection.
Re: Copy Constructor DIP and implementation
On Wednesday, 12 September 2018 at 11:39:21 UTC, Dejan Lekic
wrote:
On Tuesday, 11 September 2018 at 15:22:55 UTC, rikki cattermole
wrote:
Here is a question (that I don't think has been asked) why not
@copy?
@copy this(ref Foo other) { }
It can be read as copy constructor, which would be excellent
for helping people learn what it is doing (spec lookup).
Also can we really not come up with an alternative bit of code
than the tupleof to copying wholesale? E.g. super(other);
I could not agree more. @implicit can mean many things, while
@copy is much more specific... For what is worth I vote for
@copy ! :)
@implicit makes sense if extending explicitly implicit calls to
all other constructors gets somday considered. Some people argued
for it and I agree with them that it'd be nice to have, for ex.
to make a custom string struct type usable without having to
smear the code with constructor calls.
Re: Qt's MOC getting replicated in D for Calypso
On Saturday, 20 February 2016 at 17:34:48 UTC, Nicolas F. wrote: This is really cool and an interesting project, though I've got one concern: How will this fit in with the rest of the C++ efforts done upstream? (...) or is the goal to upstream these changes and make them an officially supported feature? The two efforts are independent, and the main issue with Calypso's approach: it's tied to LDC, LLVM and Clang. Although I had a slight hope that the approach would get recognized as allowing perfect interfacing with C++ incl. things unthinkable with the « from scratch » approach (like C++ template instantiation) and give D an edge that would probably be sufficient to make lots and lots of people switch from C++ to D, as long as DMD is there and a GDC/GCC version isn't proved feasible there's no question about whether this approach should get officially endorsed or not, and nevertheless the current efforts towards better C++ support in DMD should still yield important results. Calypso will exist as a LDC plugin, and yes code using Calypso features will only be build-able by LDC+Calypso. As I see it the goal here is to spearhead a working Qt <-> D interaction, but how would this be used in production? Would Calypso simply be run to generate bindings The goal of Calypso is to make any C++ library of any complexity usable in D straightaway, and there's no binding involved. moc was a barrier for Qt because it only parses C++ code, and Qt's C++ API can hardly be used without the code moc generates.
Re: Qt's MOC getting replicated in D for Calypso
On Thursday, 18 February 2016 at 03:07:22 UTC, Ali Çehreli wrote: Congratulations! Any project that can get rid of moc is a big achievement. :) Folks at CopperSpice had done the same in C++ with their Qt replacement: http://www.copperspice.com/ Ali Nice! I've never heard of them, interesting how they proved the moc maintainer partly wrong. On Thursday, 18 February 2016 at 03:36:20 UTC, ZombineDev wrote: Congratulations! This is an extremely promising result! BTW, what do you think about DMD's recent advancement in this area? Can you reuse some of this work for Calypso? When do you think you'll be ready to start upstreaming some of your work to LDC and/or DMD? https://github.com/D-Programming-Language/dmd/pull/5261 - Parameter types should have namespace std mangling too https://github.com/D-Programming-Language/dmd/pull/5262 - Add versioned-out branch to support new C++-11 implementations of std::string https://github.com/D-Programming-Language/druntime/pull/1470 - Add catching C++ exception support to dwarfeh.d https://github.com/D-Programming-Language/druntime/pull/1473 - add core.stdcpp.exception and core.stdcpp.typeinfo https://github.com/D-Programming-Language/dmd/pull/5330 - fix Issue 15389 - extern(C++) forward referencing problem https://github.com/D-Programming-Language/dmd/pull/5333 - fix Issue 15519 - Circular imports leads to fwd ref error with aliased imports https://github.com/D-Programming-Language/dmd/pull/5342 - C++ EH: initial front end work https://github.com/D-Programming-Language/dmd/pull/5361 - fix Issue 15579 - extern(C++) interfaces/multiple-inheritance https://github.com/D-Programming-Language/dmd/pull/5372 - fix Issue 15610 - extern(C++) multiple inheritance - calling with wrong 'this' ptr https://github.com/D-Programming-Language/dmd/pull/5397 - fix Issue 15644 - Switch object layout ABI to MI style https://github.com/D-Programming-Language/dmd/pull/5402 - fix Issue 15647 - Casting from one C++ interface in a hierarchy to another is a noop https://github.com/D-Programming-Language/dmd/pull/5403 - fix Issue 15626 - extern(C++) calling crash Most of Calypso lives independently from the C++ support in DMD, and instead queries Clang whenever possible on C++ matters. It was actually catching C++ exceptions some time before DMD (https://github.com/Syniurge/Calypso/tree/master/tests/calypso/eh), has no C++ multiple inheritance layout issue since that's handled by Clang, and the only way extern(C++) affects Calypso is by not reverting the order of function parameters so these functions can be correctly called by C++ code (function pointers, overridden virtual methods), and if I understand correctly this is only necessary because there's a discrepancy between DMD and what the docs say: http://forum.dlang.org/thread/zogygbvfszssudpae...@forum.dlang.org?page=2 When do you think you'll be ready to start upstreaming some of your work to LDC and/or DMD? My big concern is the switch to DDMD. It seems that the transition is going pretty smoothly for LDC, but what about Calypso's extensions to DMD? Calypso classes deriving from DMD ones will have to be converted to D and those classes happen to sollicit Clang's C++ API a lot, so I'm counting on C++ Calypso to build D Calypso meaning it has to be pretty solid at that point to support both Clang and LLVM. Anyway as long as both LDC and Calypso haven't both caught up with DDMD it's probably too early for upstreaming. The downside is that Calypso is marginalized, I don't get many testers (<- euphemism, only wilsonk helped a lot and right now I'm about the only one testing). The neglecting of MSVC, the "still experimental" label and the lack of releases probably don't help in that regard. It's not a big deal though since I have enough on my hands, coming next is the LDC 0.17 merge, and rework on the PCH generation that should increase the speed 3x according to cachegrind.
Qt's MOC getting replicated in D for Calypso
Hi all, I now have a working D replacement for moc: https://github.com/Syniurge/Calypso/blob/master/tests/calypso/qt5/moc For those unfamiliar with Qt, moc (the Meta-Object Compiler) is a tool that generates additional code for Qt classes, code then used by the signal/slot system, properties and other Qt-specific extensions. While C++ moc is not going away for probably a very long time (http://woboq.com/blog/reflection-in-cpp-and-qt-moc.html), D's compile-time reflection makes it possible to replicate moc's functionality entirely with templates and CTFE, with the help of some Calypso features: C++ template instantiation, overriding C++ virtual methods, and member function pointers. Calypso had been partially supporting Qt5 for a while and there was a Qt5 demo written by Kelly Wilson, but to work around the lack of moc he had to write an intermediate C++ class with virtual slots and the signal <-> slot connections were done in C++ code. Now everything is in D: https://github.com/Syniurge/Calypso/blob/master/tests/calypso/qt5/qt5demo.d The moc package is as faithful as possible to Qt 5.5.0's moc. It's not finished yet (missing: properties, class info) but signals, slots and connections are working, making Qt 5 development in D much more practical than before.
Re: Calypso progress report (+ updated MingW64 build)
On Wednesday, 25 November 2015 at 06:57:14 UTC, deadalnix wrote: I can't find the runtime that goes with this. My best guess was here: https://github.com/Syniurge/druntime/blob/release-0.16.1/src/ldc/eh/common.d But it doesn't check the source language. Can I get some pointers ? In case you haven't found already, the rest of the changes lies next door in libunwind.d. Then if you're after the differences from vanilla LDC you could ctrl+f for // CALYPSO comments (I've made a habit of tagging all the departures from vanilla code with these), or you could browse the diff from the single commit: https://github.com/Syniurge/druntime/commit/d33d8bf32c739bf9a30705dfc764718c817f16b1#diff-da783b0dc7ec2a5b78b6c4479a320d08
Re: Calypso progress report (+ updated MingW64 build)
On Tuesday, 24 November 2015 at 06:44:31 UTC, deadalnix wrote: Yeah that's what I wanted to look int he IR. Where is _D_ZTISt9exception7__tiwrap defined ? Looks like you trimed the output :( Sorry I got a little heavy handed, here's the full IR: https://paste.kde.org/piivojs0s
Re: Calypso progress report (+ updated MingW64 build)
On Monday, 23 November 2015 at 00:04:44 UTC, deadalnix wrote: I'd be very interested by the LLVM IR that this spout out. Here's the IR for https://github.com/Syniurge/Calypso/blob/master/tests/calypso/eh/std_exception.d : https://paste.kde.org/pjxrqjjhp Also, good work, pulling that one is hard. It wasn't that hard to be honest, I took many shortcuts thanks to Clang and Calypso. But even without them it's doable. About the issue you mentioned in the other thread, I don't think generating std::type_info values will be too big of a hindrance for Walter. Looking at cxxabi.h the classes derived from type_info all have simple layouts so generating values at least for classes singly inheriting from std::exception should be achievable without too much sweat.
Re: Calypso progress report (+ updated MingW64 build)
On Monday, 16 November 2015 at 19:35:58 UTC, Andrei Alexandrescu wrote: That's great progress. Do you have documentation for how things work? For example, what's the lifetime of the pointer people will get from std::exception::what(). IMHO: don't worry about catching exceptions by value; it's almost always either incorrect, uninteresting, or both. The prize is catching (references to) classes rooted in std::exception. Nice-to-have is catching (references to) classes rooted in other C++ classes. A blog post would be fantastic. Andrei Finally there: https://syniurgeblog.wordpress.com/2015/11/20/catching-cpp-exceptions-in-d/ Although a little late and probably less user-oriented than you wanted? For example, what's the lifetime of the pointer people will get from std::exception::what(). The exception object gets destroyed on exiting the catch (C++) block if the exception isn't rethrown.
Re: Calypso progress report (+ updated MingW64 build)
On Thursday, 22 October 2015 at 01:19:19 UTC, Andrei Alexandrescu
wrote:
Great news! What's the story on exceptions? Does Calypso allow
D code to catch exceptions thrown from C++ code? -- Andrei
Small update: the LDC 0.16.1 merge was done and it's now possible
to catch about any C++ exception with catch (C++) (..) {..}
statements.
https://github.com/Syniurge/Calypso/blob/master/tests/calypso/eh/std_exception.d
Output:
Throwing an ooops exception
Catching the ooops, e.what() == Ooops!
Throwing another ooops exception
Catching the std::exception, e.what() == Ooops!
Now throwing a float
Catching the float, f == 20.16!
What's left to implement for full C++ EH support:
- catching class/struct by value (it's already possible to catch
thrown class values by reference though)
- thrown object lifetime
- rethrowing
Re: Calypso progress report (+ updated MingW64 build)
On Sunday, 25 October 2015 at 21:42:15 UTC, Stefan wrote:
Hello,
// compile with: ldc2 -cpp-args -std=gnu++11 main.d
modmap (C++) "cmath";
import (C++) std._;
import std.stdio;
int main()
{
writeln(sin(cast(float)0.8159));
return 0;
}
gives a lot of "error: constexpr function never produces a
constant expression" messages. Not sure this is supposed to
work?
Hi and thank you for testing!
The code compiles and runs with C++11 disabled, I don't know why
these errors occur while generating the PCH with C++11 enabled,
looking into it.
Re: Calypso progress report (+ updated MingW64 build)
On Monday, 26 October 2015 at 01:52:37 UTC, Laeeth Isharc wrote: any chance of some release builds on github when the time is right? I've tried a few times, and somewhat embarrassingly each time I get a bit further, but still never made it to a usable version of ldc-calypso. I didn't want to file bug report as figure you have better things to do at this stage and it's a moving target. ldc itself I can compile fine (without your mods). I'd be interested in seeing if quantlib is usable. it's a library that's quite popular in finance world, and might open up the set of people that are interested in exploring D. Hi Laeeth, Were you trying to build it on Linux? I uploaded a Linux build: http://www.homo-nebulus.fr/dlang/Calypso-x86_64-Ubuntu15_04-2015_10_25.tar.xz The build process got much simpler 2 weeks ago though, now that it doesn't depend on an LLVM source tree and an external Clang executable anymore it's almost identical to building LDC. Let me know how Calypso fares with quantlib.
Re: Calypso progress report (+ updated MingW64 build)
On Sunday, 25 October 2015 at 21:42:15 UTC, Stefan wrote:
Hello,
// compile with: ldc2 -cpp-args -std=gnu++11 main.d
modmap (C++) "cmath";
import (C++) std._;
import std.stdio;
int main()
{
writeln(sin(cast(float)0.8159));
return 0;
}
gives a lot of "error: constexpr function never produces a
constant expression" messages. Not sure this is supposed to
work?
It's fixed with the latest commit.
Re: Calypso progress report (+ updated MingW64 build)
On Friday, 23 October 2015 at 09:19:44 UTC, Kagamin wrote:
On Thursday, 22 October 2015 at 23:24:57 UTC, Elie Morisse
wrote:
Default constructors are invoked
Including class fields?
class A
{
QString s_myFilename;
this()
{
//is s_myFilename constructed already?
}
}
That triggered my own assert, oops. It's fixed now, the field
default ctor is called if the field has no initializer, just
before A's ctor.
Re: Calypso progress report (+ updated MingW64 build)
On Thursday, 22 October 2015 at 18:02:08 UTC, Kagamin wrote:
Cool, is that a value type QString? Really? Then functions in
Qt5 demo should accept QString by ref to better match C++.
Not sure if I already announced it here but one major change a
few months ago is that all C++ classes are now value types, it
made things a lot saner.
I think the reason why Kelly didn't use ref was to be able to
write loadFile(QString("myFilename")) instead of:
auto s_myFilename = QString("myFilename");
loadFile(s_myFilename); // only takes lvalues
Add me to the people who'd really love D to get through this once
and for all btw :)
Are copy constructors and assignment operator invoked?
As I see default constructors are not invoked yet?
Default constructors are invoked, and I should have added another
line to the list of main features:
• Maps C++ overloaded operators to D operators when an
equivalent exists (and others are mapped to normal functions
named e.g __opUnaryArrow for operator->)
Since D doesn't support non-member overloaded operators those
aren't usable as in C++, I need to work on a solution for this
(there's already some groundwork actually, non-member operators
that take for example a std::basic_string left operand are mapped
as part of the std.basic_string module).
Currently copy constructors aren't invoked when calling functions
with class/struct byval arguments, arguments are memcpy'd. This
is another important missing feature I should implement asap.
Re: Calypso progress report (+ updated MingW64 build)
On Thursday, 22 October 2015 at 06:28:06 UTC, Suliman wrote: Does it's mean, that Calypso can be work as plugin for Clang? As a LDC plugin, so that LDC doesn't depend on Clang. On Thursday, 22 October 2015 at 15:22:16 UTC, Szymon Gatner wrote: Wow, this is fantastic. What about Windows and iOS support? MSVC hasn't been tested since 5 months ago. Calypso built by MSVC compiles basic examples but last time we tried none of the C++ standard lib test cases worked. Maybe it's better now that the template support is more robust but I've postponed work on MSVC until LDC 0.16 which includes the Win64 work by kinke. The MingW x86 build works better and compiles most libstdc++ samples but hasn't been tested much either. I'll come back to MSVC after improving the C++11 support, because one Achilles' heel of Calypso is currently whenever template argument deduction is involved and both MSVC's standard lib and C++11-enabled GNU libstdc++ makes heavy usage of template argument deduction. It's because Calypso relies on a hack that doesn't handle every case yet, although the situation has improved a lot and it works well enough to handle some Boost libraries.
Re: Calypso progress report (+ updated MingW64 build)
On Thursday, 22 October 2015 at 01:19:19 UTC, Andrei Alexandrescu
wrote:
On 10/21/2015 07:40 PM, Elie Morisse wrote:
It's been a while since the last update, so here's a quick one
before
making the jump to LDC 0.16.
Great news! What's the story on exceptions? Does Calypso allow
D code to catch exceptions thrown from C++ code? -- Andrei
Hi Andrei,
Not yet but I've looked into it, the plan is to add:
catch (C++) (...) { }
statements and make Clang translate them into C++ landing pads
(as for imports the parser will query the language plugins when
encountering two pairs of (), so the C++-specific statement will
be part of Calypso, not DMD).
Then add a "C++ exception class" handler in LDC's personality
function:
https://github.com/ldc-developers/druntime/blob/ldc/src/ldc/eh/libunwind.d#L327
Easier said that done but Clang should make the std::type_info
matching doable.
So it's on the roadmap just after the merge of LDC 0.16.
Calypso progress report (+ updated MingW64 build)
It's been a while since the last update, so here's a quick one before making the jump to LDC 0.16. Kelly added a more complex Qt5 demo, I recently added an Ogre3D one: https://www.youtube.com/watch?v=eryhDOa9MV0 https://github.com/Syniurge/Calypso/blob/master/tests/calypso/ogre3d/demo.d Ogre3D is a much more "sophisticated" creature than Qt5, relies on some Boost libraries, so Calypso had to reach quite another level to support it. As a reminder Calypso (https://github.com/Syniurge/Calypso) is an experimental LDC fork which lets you use C/C++ libraries without having to write bindings. Its main additions: • Maps C++ functions, global variables, structs, classes, unions, enums, typedefs, templates • C++ class and function template instantiation (including global variables inside class templates with their proper initialization in the global ctor) • C++ class creation with the correct calls to ctors (destruction is still disabled) • Virtual function calls • Static casts between C++ base and derived classes (incl. multiple inheritance offsets) • D classes inheriting from C++ classes, including the correct vtable generation for the C++ part of the class (except for MSVC which has a different ABI) • Debug info generation for any C++ symbol instantiated by D code The roadmap is: merge upstream LDC 0.16 into Calypso → C++ exception support → better C++11 support → MSVC support → extend magicport2 to convert Calypso to D (and Calypso could "bootstrap" itself to avoid writing bindings to Clang) → make Calypso an optional shared library On Linux Calypso should be in a state usable enough to start a project assuming the lack of C++ exceptions or class destruction isn't a blocker to start it (but I'm looking into the latter right now), it has held up quite well while expanding the Ogre and Qt5 demos, and my own project based on Qt5 and OpenCV. So far only Kelly Wilson has been testing Calypso with various libs and expanded the test cases (most of the libstdc++ samples are his), so more testing would be very helpful. Updated MingW build: http://www.homo-nebulus.fr/dlang/Calypso-Mingw64-i686-4.9.3-posix-dwarf-rt_v4-rev1.tar.xz
Re: Calypso: Direct and full interfacing to C++
On Tuesday, 19 May 2015 at 17:44:38 UTC, CraigDillabaugh wrote: Just to clarify then. If gdalwarper.h includes gdal.h and GDALDatasetH is declared in gdal.h, then gdal.h gets imported too? Craig On Tuesday, 19 May 2015 at 19:57:45 UTC, Suliman wrote: How do you understand which files should be imported? +1 for question! modmap is only telling Clang which headers to parse. Then all those headers form a big monolithic AST that Calypso split into modules following a few rules: import (C++) namespace1.testStruct; // imports namespace1::testStruct import (C++) namespace2.testClass; // imports namespace2::testClass import (C++) test.anotherClass; // etc. each struct/class/enum template or not is placed in a module named after it import (C++) test.tempWithPartialSpecs; // imports the primary class template + all its partial and explicit specializations import (C++) test._; // « _ » is a special module that contains all the global variables, global functions and typedefs of a namespace (the ones which aren't nested inside a struct or a class, or another namespace). Why the header paths can't be used in imports is explained here: http://syniurge.blogspot.fr/2013/08/calypso-to-mars-first-contact.html#namingquestion Documentation is scarce at the moment, the examples (starting with showcase.d) try to give a quick overview of how to use Calypso but yep we really should write a tutorial of some sort, either I or Kelly will do it before DConf.
Re: Calypso: Direct and full interfacing to C++
On Tuesday, 19 May 2015 at 17:44:38 UTC, CraigDillabaugh wrote: Just to clarify then. If gdalwarper.h includes gdal.h and GDALDatasetH is declared in gdal.h, then gdal.h gets imported too? Craig So to give a more straight answer, modmap is an #include directive so every header gdalwarper.h includes will be parsed too. But it doesn't import anything.
Re: Calypso: Direct and full interfacing to C++
On Tuesday, 19 May 2015 at 08:02:47 UTC, Suliman wrote: Oh, I forgot to fix path at: /etc/ldc.conf Am I right understand that: C:/Program Files (x86)/ldc/lib = C:\Program Files (x86)\mingw-w64\i686-4.9.2-posix-dwarf-rt_v4-rev2\mingw32\lib ? Or I can't find more proper folder The Unix path for C:\Program Files (x86)\mingw-w64\i686-4.9.2-posix-dwarf-rt_v4-rev2\mingw32\lib is simply: /lib. ( The root the leftmost / refers to in every Unix path is C:\Program Files (x86)\mingw-w64\i686-4.9.2-posix-dwarf-rt_v4-rev2\mingw32 ) You're almost in uncharted territory, but thanks for helping with testing! I'll write clearer instructions for Windows too when I get the time. And BTW the MingW build is pretty old by now. I don't have much free time atm and I'm working on important fixes, but as soon as they're ready I'll update the MingW build.
Re: Calypso: Direct and full interfacing to C++
On Monday, 18 May 2015 at 12:27:35 UTC, Kagamin wrote: BTW how does it rely on having everything on the D side? Maybe it's enough to have just instance size and method symbols? I'm not sure what you mean. But then there's problem with this inference: what if the type is intended to be used as a reference type and you infer it to be POD, and it can also flicker between POD and non-POD depending on defines. This is true and it may not even be rare: turning C++11 on or off is doing it for some Qt classes. But there is another issue that will make me revisit their semantics anyway, it's that C++ structs and classes shouldn't be garbage collected because they weren't made with GC in mind and might have weak refs. So unless someone has a better solution C++ classes will go back to manual memory management, and the plan is while changing class and new's semantics to also make all C++ classes values.
Re: Calypso: Direct and full interfacing to C++
On Sunday, 17 May 2015 at 13:37:45 UTC, Suliman wrote: Where set where Calypso should look header files? It works the same as in C++, there are the standard header paths: /usr/include, /usr/include/c++/4.9, /usr/local/include And to add another header search path you can pass options to Clang with -cpp-args, i.e « ldc2 (...) -cpp-args -I/another/include/folder ». With the MingW version all those Unix paths refer to the MingW root directory.
Re: Calypso: Direct and full interfacing to C++
On Wednesday, 13 May 2015 at 15:54:47 UTC, John Colvin wrote: That's great! I'm looking forward to being able to easily make direct use of some of the great C++ code out there. Are there are performance pitfalls to watch out for that are unique to the way calypso interfaces between D and C++? E.g. sneaky copies, implicit callbacks to keep things synced etc. There are a few: - Many simple non-POD C++ classes are being mapped to D classes instead of structs, for example QFlagsAlignmentFlag (qt5demo.d uses its alias Qt::Alignment) which is a wrapper around a single int but contains an overloaded assignment operator so is considered non-POD in C++. Same story for QString. string, vector, almost all STL types are non-POD too because they have base classes. So this may be inconvenient when trying to avoid heap allocations.. For QFlags and QString we could do more than just checking if the class/struct is POD according to the C++ definition (i.e we could ignore overloaded operators, which are allowed in D structs), but STL types will most likely stay that way. - For the time being when calling a C++ function taking a class value argument with FunctionB(new ClassA(...)), the ClassA instance is 1/GC-allocated 2/ctor is called 3/copied to the stack-allocated memory for the call. Whereas in C++ FunctionB(ClassA(...)) the ClassA constructor is directly called over the stack-allocated memory. In D there's no way to avoid the copy yet, I think we could mimic the C++ way but that'd involve another small alteration to the language. That's about it, I can't think of anything else, what's cool is that almost all symbols Calypso exposes are the C++ symbols themselves with no wrapper layer in-between, with a few exceptions such as overloaded operators opBinary!+ etc. which dispatch the call to the C++ operator mapped to a non-templated function (because the C++ overloaded operator might be virtual, it can't be mapped directly to a template).
Re: Calypso: Direct and full interfacing to C++
On Thursday, 14 May 2015 at 20:23:47 UTC, Laeeth Isharc wrote: Elie, Congratulations on this very impressive work. Out of curiosity, how far away do you think it is from being at a beta stage that one can use to write non-critical work in ? Thanks Laeeth, It's not too far I think. When finally comes the time when I can test one or two new complex libraries without triggering new bugs it should be good enough. At the moment I'm focusing on libraries that depend on Boost and are one order of magnitude more sophisticated than Qt, once they work the way out to usable state with any library may be in sight. One open source library that might not be too tough but would have high value in the financial domain is Quantlib. (I don't think it is heavily templated, but I don't yet know the codebase well). https://github.com/lballabio/quantlib Also, I am embarrassed to confess that I still have trouble building calypso (although I can build LDC fine). Specifically some symbols not found during compilation. I can pull them out if helpful, but I have tried several times over the past months and it is different ones each time. Missing symbols might be caused by your LLVM source tree having a different version from Arch's LLVM libraries. The changes made to LDC's CMake file are very primitive and won't check if the selected LLVM include/ and libraries match the one in LLVM_SOURCE_PATH added by Calypso. If you built and installed LLVM + Clang 3.6 yourself to /usr/local and if there's a different version from Arch packages in /usr, check that cmake got the right LLVM_CONFIG path with: $ cmake -LA |grep LLVM If it didn't fix the value with $ cmake -DLLVM_CONFIG=/usr/local/bin/llvm-config ../Calypso Which commit of Calypso should I use, and which versions of clang and llvm? I am using arch linux. The versions are the ones in the README, i.e the 3.6 branch of LLVM, Clang and compiler-rt. I'll add a note about the not very smart detection of LLVM libs, and if some of the instructions in the README are still confusing or incomplete please tell me.
Re: Calypso milestone hit: D adaptation of Qt5 tutorial working
On Saturday, 9 May 2015 at 19:16:33 UTC, Elie Morisse wrote: On Saturday, 9 May 2015 at 02:58:58 UTC, Mike wrote: Question: You are using a modified version of LDC, but is that compiler required to consume link to a library created with that custom compiler? What I mean is: Can you use this modified version of LDC to create a library, and then use a generic D compiler to build an application that links to that library? If you manage to hide every C++ symbol from the normal compiler I should have said, sorry for the vague answer. Linking would work like with normal D libraries, but the .d or .di files parsed by the normal compiler would have to be emptied of C++ imports so any symbol those imports provided shouldn't appear in the .di file.
Re: Calypso milestone hit: D adaptation of Qt5 tutorial working
On Saturday, 9 May 2015 at 02:58:58 UTC, Mike wrote: Question: You are using a modified version of LDC, but is that compiler required to consume link to a library created with that custom compiler? What I mean is: Can you use this modified version of LDC to create a library, and then use a generic D compiler to build an application that links to that library? If you manage to hide every C++ symbol, including C++ class/struct/enum types, that should work. On Saturday, 9 May 2015 at 09:56:03 UTC, Rainer Schuetze wrote: Probably discussed before, but as an alternative to a library, would it be possible to use the header generation (-H) to emit .di files compatible with other compilers? I don't think this is possible since C++ functions for instance are mapped directly and not wrapped inside a D function, and only the Clang libraries know how to properly emit a call.
Calypso milestone hit: D adaptation of Qt5 tutorial working
Hi! Calypso just got a D translation of the first Qt5 Widgets tutorial building and running: https://github.com/Syniurge/Calypso/blob/master/tests/calypso/qt5/qt5demo.d Result: http://homo-nebulus.fr/dlang/oh%20my.webm Compilation log: https://paste.kde.org/pewbbsw45 Previously Calypso was merely able to work with STL types, this is the first time a large C++ library is successfully mapped and used by D code (Ogre3D is probably close as well, but after Kagamin's suggestion and for a change of scene I switched my focus from Ogre3D to Qt).
Re: Calypso: Direct and full interfacing to C++
On Wednesday, 22 April 2015 at 14:57:43 UTC, Kagamin wrote: What about Qt? I don't remember it being heavily templated. Thanks for the hint, it's definitely true for most of the code of Qt although there are still a few areas like QtCore/qtypetraits.h or Q_STATIC_ASSERT in non-C++11 mode that are tormenting Calypso (and helped fix bugs). But overall it seems like a much shorter list of errors compared to other libs, so there may be something to show soon :) On Wednesday, 29 April 2015 at 15:33:38 UTC, Kelly wrote: This isn't a problem anymore because Calypso can import libraries without an explicit namespace now, as long as it has a modulemap (that was part of the updating effort over the last week). Actually it's not due to that directly but because there were a few Qt global functions and variables (e.g in QtCore/qnumeric.h) that some Qt classes depend upon and caused a large part of the C standard lib to be imported, which would fail because there are some variables and structs that share the same name. It works properly now that symbols from the C standard lib are split across several modules (so no more name conflicts).
Re: Calypso: Direct and full interfacing to C++
On Thursday, 16 April 2015 at 06:43:25 UTC, Suliman wrote: Could anybody wrote very simple tutorial, that show how to use any popular C/C++ lib without binding? I mean step by step manual. Also it would be nice to get binary builds for Windows to test. Sorry for the wait. So Calypso still can't load the MSVC C++ standard lib. I thought Kelly managed to build some STL examples but actually it's not remotely possible yet. The main blocker is that template instances often depend on each other (but not in their entirety) which cause forward reference errors in DMD. However it works with MinGW-w64, but this wasn't remotely straightforward either, I had to modify Clang to make it detect correctly the MinGW paths (which are hardcoded in Clang and obsolete): - install mingw-w64, in the installer choose 4.9.2, DWARF exceptions and POSIX threads - download http://homo-nebulus.fr/dlang/Calypso_mingw-w64.7z - extract the archive over the MinGW root directory (where the bin/, etc/, etc. folders lie) - correct the paths in /etc/ldc.conf - add Z:\path\to\MingW\bin to your PATH environment variable in your System settings (e.g follow: http://geekswithblogs.net/renso/archive/2009/10/21/how-to-set-the-windows-path-in-windows-7.aspx) Then you can build the examples in tests/
Re: Calypso: Direct and full interfacing to C++
I should have given the same warning, there's a chance that Calypso may work with not too sophisticated C++ libraries but new bugs are around the corner if you try anything too big. Nevertheless Suliman, Laeeth and maybe others have been wanting to try it out in its current state, and it was useful because new errors seems to have appeared while compiling the STL examples by a MSVC build since Kelly's successful attempt two months ago (no idea whether it's because more of the MSVC runtime/standard lib gets mapped or because he used another standard lib?). So sorry for the wait but this is taking longer than expected, first I could only start building LLVM yesterday's evening because of slow download speeds, and today the MSVC build is triggering these new errors I'm investigating.
Re: Calypso: Direct and full interfacing to C++
On Thursday, 16 April 2015 at 06:43:25 UTC, Suliman wrote: Could anybody wrote very simple tutorial, that show how to use any popular C/C++ lib without binding? I mean step by step manual. Also it would be nice to get binary builds for Windows to test. Suliman sorry for keeping you waiting :) I'll be spending the evening installing MSVC and Qt Creator, and building Calypso for Windows users to play with and to help with testing. Expect binaries tomorrow. The usage should be clear just by looking at and building the examples in tests/calypso.
Re: Calypso: Direct and full interfacing to C++
Sorry for the lack of updates, progress was a bit boring for the past 2 months and consisted mostly in crawling my way up a bottomless pit of errors generated by « import (C++) Ogre.Light; ». And then this happens: https://paste.kde.org/pse8pqzch :D The compilation speed could be improved, more bugs should get triggered by actual usage of Ogre, but close to everything gets mapped, semantic'd and codegen'd and this is the milestone I've been working towards for months. Last week also introduced was the Clang module map file support, which helps breaking namespaces into smaller pieces and thus makes probably most C libraries usable right now without having to maintain bindings, only a module map file which may also be generated by clang-modularize.
Re: Calypso: Direct and full interfacing to C++
On Tuesday, 24 February 2015 at 08:44:25 UTC, Kagamin wrote: On Tuesday, 24 February 2015 at 08:39:39 UTC, Kelly wrote: due to class value support being incomplete What about using that trick: recognize C++ classes and represent them internally as structs with altered mangling - at least it frees you from messing with D classes. What about inheritance, polymorphism and virtual methods that aren't supported by D structs? I'm worried that it's going be a lot harder to reimplement everything in structs. Atm to quickly make functions that take or return class values work what's missing is implicit casts between the class value types I added recently (the hacky TypeValueof) and the normal class types, and support in codegen. So it's not too far away I think.
Re: Calypso: Direct and full interfacing to C++
On Wednesday, 18 February 2015 at 08:52:33 UTC, Kelly wrote: Hello Elie, I just pushed a small pull request for fromTypeTemplateSpecialization. I forgot to mention in the request that the changes allow bitset.d to be compiled and run again. Thanks for looking into this, I'll check your PR. With those changes all the examples compile and run again. There are still two errors when compiling vector.d. Clang errors when making the pch file. LDC2 still runs and produces a working binary anyways. Not sure what you are working on, but I can look at those errors if you like. Are these errors occurring when Clang generates the PCH or later in the semantic pass? There might be errors during the instantiation of member functions of class templates because Calypso tries to instantiate everything (whereas Clang instantiates them lazily), but it's no big deal, later they'll be made silent. BTW I just pushed support for function template instantiation. So lately thanks to a bit of free time there has been quite a lot of new features implemented: overloaded operators, function templates, and groundwork for class value types (they were added to the AST as a new semi-hackish kind of type, they make mapping any C++ type possible but they can't be used directly from D code yet). Operators should make std::map usable, so I'm going to resume testing further STL types.
Re: Calypso: Direct and full interfacing to C++
Hi Kelly, It's done, I've merged latest LDC upstream + your build fixes into Calypso. About Microsoft vtables they work much more differently from the Itanium ones than I thought, it's going to a lot trickier than just a few lines of code so I won't be able to make D classes inheriting from C++ ones work on MSVC until I setup a dev environment on Windows. It's just those « D-C++ classes » though, the rest has a better chance to work now.
Re: Calypso: Direct and full interfacing to C++
On Sunday, 15 February 2015 at 11:48:50 UTC, Kelly wrote: Alirighty, Calypso builds and runs on both Linux and Win64 with that last change from today in my fork. Now when I say 'runs' on Linux, I mean it runs properly and fully (compiling and running all examples from Feb 8th)...but when I say 'runs' on Win64, I should say 'runs as far as it can' because there is an internal LLVM assert with getVTableContext Microsoft VTableContext not yet supported UGH! :( It's from Calypso actually, the assert is in gen/dcxxclasses.cpp and is only triggered by D classes inheriting from C++ classes with a vtable. If the rest works as usual on Linux you got the most important covered. I'll check your merge as soon as I'm done fixing a linking error with the std::string example the latest additions introduced, then I'll add the Microsoft VTableContext support so we could get those first working binaries for Windows users :) However LLVM and Clang 3.6 aren't even released yet (next week), IMHO it would be wiser to stick with 3.6 and get LDC/Calypso working with 3.6 until 3.7 is more stable. Did you mean that even LDC can't be built by MSVC with LLVM 3.6 atm?
Re: Calypso: Direct and full interfacing to C++
Anyway I'm probably fixing the last issue right now preventing std::vector from instantiating so I'm going to push the commits to master in the hour.
Re: Calypso: Direct and full interfacing to C++
On Friday, 13 February 2015 at 09:49:51 UTC, Kelly wrote: Hello Elie, Ok, I have merged in the newest LDC with Calypso from github today and built it with vs2013 on Win7 :) There is a small diff involved in getting things to compile. The resulting ldc2 runs and builds a simple hello world program, but it fails when trying to use calypso. I guess I've made a mistake with my patch since I am getting an assert in ASTReader with input for calypso to compile. I will look at it tomorrow and once I can get calypso to work I will push to my github fork. Hoping for better news tomorrow, Kelly Awesome news Kelly. Did you use rebase to merge? You've probably saved me a lot of work which I was planning to do this week-end after seeing your post about Win64 support. There are a dozen of new commits in store since last week-end for operator support and groundwork for class values, but mapping operators trigger new bugs which prevent std::vector from instantiating so I haven't pushed them yet to master, but do you want me to push them into a new branch so you can merge with the latest? Let me know when you make your fork available so I can check your merge and then incorporate it into master.
Re: Calypso: Direct and full interfacing to C++
On Monday, 9 February 2015 at 04:27:06 UTC, Kelly wrote: Thanks, just got that tangled mess of templates that is std::string working too: Hey Elie, this is great stuff, as usual. I have written a test file for bitset here also (including a couple failures I am sure you are aware of, but others might want to see what works and what doesn't). Hi Kelly, Good to see bitset instantiating and basically working too! Can I add your code to the tests? So yes to clear things up a bit, operators are still missing and so are many other features. Off the top of my head: - Function templates = the groundwork is here, they're already mapped and it shouldn't be too difficult to get them instantiating from D - Operators = probably easy to add although there might be differences between C++ and D operators - Functions with class values parameters aren't even mapped yet, since I haven't made my mind on how to handle class values. Despite the POD or not issue it still feels more consistent to treat C++ classes like D classes, while adding C++ class value types to DMD's types like C++ reference types were with TypeReference (which makes C++ variables with reference types usable but which can't be assigned as the types of D variables) - C++ reference types are supported by DMD but not by LDC yet, they only work for function parameters and return types since Calypso replace them by ref
Re: Calypso: Direct and full interfacing to C++
On Monday, 9 February 2015 at 07:10:56 UTC, Suliman wrote: If somebody have working Windows build, could you please share it? It would be nice to know if someone even managed to build Calypso on Windows yet :) On Monday, 9 February 2015 at 20:17:33 UTC, Andrei Alexandrescu wrote: You may want to put this on reddit too (unless you're the one who did): http://www.reddit.com/r/programming/comments/2vc0eg/calypso_dc_interface_using_stdvector_and/ Andrei Nice, I'll dust my antique barely used account if questions pop up.
Re: Calypso: Direct and full interfacing to C++
Small update: std::vector is now working. https://github.com/Syniurge/Calypso/blob/master/tests/calypso/libstdc%2B%2B/vector.d I went back to simpler problems than getting Ogre to work and will focus on the C++ standard lib until the common class templates work.
Re: Calypso: Direct and full interfacing to C++
On Sunday, 8 February 2015 at 20:56:31 UTC, Syro wrote: That is really cool. Thanks, just got that tangled mess of templates that is std::string working too: https://github.com/Syniurge/Calypso/blob/master/tests/calypso/libstdc%2B%2B/string.d
Re: Calypso: Direct and full interfacing to C++
Hi Laeeth, Could you post the errors and which compiler you are using? If you managed to build both LDC and Clang you should be pretty close to get Calypso working. Would there be any chance you could fork a version of clang that works with Calypso, and then link to it in the instructions? As said in the README the 3.5 branch of LLVM/Clang should work, it's stable and there hasn't been a single commit since December 8: https://github.com/llvm-mirror/clang/commits/release_35
Re: Calypso: Direct and full interfacing to C++
On Friday, 23 January 2015 at 12:29:56 UTC, Kelly wrote: Hello Elie, This project looks great, thanks for the hard work. I downloaded Calypso and ldc2 about 6 hours ago to try your project out. I can get Calypso to compile with a couple small changes to assistbuilder.cpp (just adding a namespace qualifier for two class instantiations of CodeGen). That is with clang-3.5 from todays svn. Maybe a recent clang commit has changed things? Once I had a working Calypso ldc2 build, I unfortunately couldn't get the showcase example to build. I just use the build line from your git page to try to build, but I get an 'undefined identifier size_t' error. The pch file is produced properly but then this error comes up...it seems like while compiling druntime from the '-v' output?? Maybe something changed in the druntime submodule in the last few days...but I didn't really look into it yet. I hacked a couple things to just get around this error and then things fail because libshowcase.a isn't available. I assume that is a remnant from an earlier compilation technique, because it appears everything is self contained in the .o files being produced and then linked on the command line...so I just thought I would let you know this part doesn't work. If you could give me a hint on the 'undefined identifier size_t' error, I can look into it a bit further here...I am just getting tired and probably not seeing what is going on there. If you are on #ldc I will be on there later today. Not sure what your username is in #ldc. At least one other person has been by asking if you were there also :) Thanks, Kelly (wilsonk-laptop) Thanks for the feedback Kelly, you're probably the first person to give it a serious try, sorry for the bumpy ride :) Since I was focused on getting Ogre working and neither rebuilt druntime/phobos nor tested the showcase example against the latest commits they might have broken something. Also the README forgets to say how libshowcase.a should be built: clang++ -std=c++11 -c showcase.cpp -o showcase.cpp.o ar rcs libshowcase.a showcase.cpp.o ldc2 -cpp-args -std=c++11 -Llibshowcase.a -L-lstdc++ showcase.d Adding this now. I'm going to fix the rest this afternoon (finally some free time), and also figure out why assistbuilder.cpp failed to compile against the latest Clang 3.5. Also going to setup a testing script to ensure not everything gets broken again by a commit.
Re: Calypso: Direct and full interfacing to C++
On Friday, 23 January 2015 at 10:02:55 UTC, Jacob Carlborg wrote: Could this work for Objective-C as well. I'm working on adding support for Objective-C to DMD [1]. [1] https://github.com/D-Programming-Language/dmd/pull/4321 It's planned to add Objective-C to Calypso, although I never used it and know little about it. Would you be interested in implementing support for its different flavors in Calypso, Jacob? You'd be welcome to the team :-)
Re: Calypso: Direct and full interfacing to C++
Nevermind it's just that CodeGen is ambiguous with clang::CodeGen although my compiler doesn't complain. Fixed.
Re: Calypso: Direct and full interfacing to C++
On Friday, 23 January 2015 at 23:06:16 UTC, Kelly wrote: People might still need the small quick fixes for gen/cpp/assistbuilder.cpp, but just adding clang:: in a couple spots shouldn't be too arduous for anybody if they really want to compile and play with Calypso. Weird, assistbuilder.cpp compiled fine here with up-to-date Clang 3.5. Did you checkout the 3.5 branch?
Re: Calypso: Direct and full interfacing to C++
On Thursday, 22 January 2015 at 07:27:03 UTC, Suliman wrote: First you need a LLVM + Clang 3.5 source tree, built libraries and the Clang binaries. Installing binary packages from your distribution isn't enough since the include/ files aren't exposing many symbols, so the source packages are needed as well Do I need to compile from source just Clang or both? Usually Clang is built with LLVM, i.e running make inside the LLVM build directory will build both LLVM and Clang. On Thursday, 22 January 2015 at 07:07:42 UTC, Suliman wrote: Currently making D classes derive from C++ classes with a virtual table only works with MinGW because only the Itanium ABI is supported. I'm going to add the Microsoft ABI ASAP (it's just a few lines of code) but it'll be untested. Could you explain can I call function from C++ dll directly? I am need only basic C++ support -- just ability to call very basic functions. Am I right understand that with Calypso I do not need to create bindings? If it's correct - could you provide any example of calling C++ function from dll? On Windows the Clang executable has to be in one of the %PATH% folders and then in your D code: modmap (C++) headerofyourdll.h; // will make Clang generate a precompiled header import (C++) Namespace1.Namespace2._; // If your functions are global functions inside Namespace1.Namespace2, _ is a special module (for now) that contains all the global funcs, vars and typedefs import (C++) Namespace1.Struct1; // If they are inside a struct named Struct1 The imports expose symbols that you can use like you'd use D structs and functions. Finally you need to tell LDC to link to your library: ldc -L=yourDLL.lib (...)
Re: Calypso: Direct and full interfacing to C++
On Thursday, 22 January 2015 at 00:08:13 UTC, Walter Bright wrote: Just making STL work would be an achievement! Is the output of Calypso a file that can be imported? The only outputs specific to Calypso are ligthweight object files per C++ module that contain symbols created by LDC for aggregates (InitZ...) and template specializations by Clang if they're not defined in the PCH. What Calypso basically does is tell Clang to generate a big PCH for all the headers in modmap directives, and to map on demand C++ declarations from the PCH to D symbols in a separate tree of modules (hence the (C++) in imports, they're not physical modules). Those symbols can be used like D's, although they have different implementations to handle the C++ specificities, and all the non-trivial semantic work is done by Clang libraries and queried back by Calypso (aggregate layout, partial template argument deduction, ...). There are still some very feels hackish areas like the fact that DMD considers C++ classes to derive from Object too (fortunately Object is only a handful of virtual functions), I haven't solved yet how class values should be treated, etc. Also the PCH is a temporary solution because at the time I began working on Calypso Clang's support for modules was broken. But they would be great to break the global namespace in smaller pieces, so now that they seem ready to use the plan is to replace the PCH by them, or by a slightly different flavor of them (because there's currently one limitation that reduces its usefulness, it's that one header can't be split across several modules).
Re: Calypso: Direct and full interfacing to C++
On Wednesday, 21 January 2015 at 10:37:18 UTC, Suliman wrote: Could you explain how to build it's on Windows. I read readme, but do not fully understand what I should to to to get it's work? You should follow the guides for LDC only you need to build Clang 3.5 as well beforehand and add the -DLLVM_SOURCE_PATH=/path/to/llvm/source/tree argument to the cmake command while building Calypso. Using Visual Studio: http://wiki.dlang.org/Building_and_hacking_LDC_on_Windows_using_MSVC Using MinGW : http://wiki.dlang.org/Building_LDC_on_MinGW_x86 Currently making D classes derive from C++ classes with a virtual table only works with MinGW because only the Itanium ABI is supported. I'm going to add the Microsoft ABI ASAP (it's just a few lines of code) but it'll be untested. On Wednesday, 21 January 2015 at 21:27:27 UTC, Walter Bright wrote: I think this is an exciting development! Considering the new D support for C++ namespaces, template mangling, etc., I think it would make Calypso's job easier. The big challenge is to get an interface to C++ STL, so one could do: import core.stdcpp.stl.vector; for example. I'd also like to encourage you to submit a Dconf 2015 presentation proposal on this. Thanks, Walter! A small update since the announcement: instantiation of C++ class templates is now working, with the right partial specialization selected if any. I'm still working as fast as I can to get Ogre3D working. Ogre3D makes wide usage of the standard C++ library so getting it running would be a milestone and at that point most C++ libraries will be usable or in close reach as well. And it'd also make a sweet demo :)
Re: Calypso: Direct and full interfacing to C++
On Tuesday, 23 December 2014 at 11:53:38 UTC, Dicebot wrote:
By upstream I don't mean LDC upstream but D upstream - we don't
want it to become part of full language spec if implementation
is so reliable on specific toolchain. It has been already
discussed when Jacob proposed dstep integration AFAIR.
Actually it's meant to be optional and Calypso should ultimately
go in a separate shared library.
As I implemented it I added this virtual function to Dsymbol:
virtual LangPlugin *langPlugin() { return NULL; }
The import (C++) create cpp::Decl which derive from the DMD
Decl and override some of its parent methods. E.g:
bool isBaseOf(::ClassDeclaration* cd, int* poffset) override;
makes isBaseOf take into account multiple inheritance and ask
Clang to compute the right offsets.
Then in gen/, there is a different kind of hook which checks if a
langPlugin is attached to the declaration:
if (auto lp = s-langPlugin()) // yeah C++11, it's a prototype
return lp-codeGen()-toCallFunction(s, ...);
And that way neither DMD nor LDC has to depend on Clang. The
intrusions are the methods made virtual and the hooks, but if no
language extension is present LDC would work as usual.
Re: Calypso: Direct and full interfacing to C++
On Tuesday, 23 December 2014 at 15:20:18 UTC, Kagamin wrote: On Monday, 22 December 2014 at 23:14:44 UTC, Elie Morisse wrote: • Structs https://github.com/Syniurge/Calypso/blob/master/tests/calypso/showcase.d testClass cls = new testInherit; This should be written testClass* cls = new testInherit; In C++ struct and class differ only in symbol mangling. They are both value types, support inheritance, copy constructors etc. By looking at the declaration you can't decide if a class should be used as value type or reference type, so better treat it as value type like in C++. At the moment Calypso maps C++ POD records to D structs, and non-POD ones to D classes. But then it's true that this creates a conundrum because I can't translate class value types to D types, so currently functions that expect class value arguments are ignored. Making C++ classes value types would have lots of implications, so the way I see it (for now, not sure if that's the best solution) I'll probably stick to D class semantics but I'll have to create C++-specific class value types to map C++ fields or functions that take class value arguments.
Re: Calypso: Direct and full interfacing to C++
On Tuesday, 23 December 2014 at 15:20:18 UTC, Kagamin wrote: On Monday, 22 December 2014 at 23:14:44 UTC, Elie Morisse wrote: • Structs https://github.com/Syniurge/Calypso/blob/master/tests/calypso/showcase.d testClass cls = new testInherit; This should be written testClass* cls = new testInherit; In C++ struct and class differ only in symbol mangling. They are both value types, support inheritance, copy constructors etc. By looking at the declaration you can't decide if a class should be used as value type or reference type, so better treat it as value type like in C++. Ah and you're right that this might confuse the user since he has to know whether the class/struct is POD or not to know whether to use values or references. Hmm.. also simply adding a virtual function to a C++ class would break the D code which previously considered that class POD :) So maybe you're right, it might be a better idea to make C++ classes values.
Calypso: Direct and full interfacing to C++
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.
Re: Calypso: Direct and full interfacing to C++
On Tuesday, 23 December 2014 at 00:01:30 UTC, Rikki Cattermole wrote: Will you be upstreaming this? Or maintaining this completely yourself? The ultimate goal is upstream, but first I need to agree with the main DMD and LDC contributors about how this should really be done. I.e atm the Calypso code coexists with the vanilla C++ support which has a different coding philosophy and is more intertwined with the rest of the code. So I expect that I'll have to maintain it myself quite some time before this happens. And of course I'll make Calypso catch up with upstream LDC frequently.
