Re: Interfacing D to existing C++ code
On Sunday, 1 February 2015 at 22:32:37 UTC, Sativa wrote: On Friday, 23 January 2015 at 11:04:12 UTC, Walter Bright wrote: Mandatory reddit link: http://www.reddit.com/r/programming/comments/2tdy5z/interfacing_d_to_legacy_c_code_by_walter_bright/ There's been a lot of interest in this topic. Interesting... I wonder if two things could happen: 1. A tool could be written to generate the interfacing code in D from the C++ code? SWIG, but the quality is not there.
Re: Interfacing D to existing C++ code
On Friday, 23 January 2015 at 11:04:12 UTC, Walter Bright wrote: Mandatory reddit link: http://www.reddit.com/r/programming/comments/2tdy5z/interfacing_d_to_legacy_c_code_by_walter_bright/ There's been a lot of interest in this topic. Interesting... I wonder if two things could happen: 1. A tool could be written to generate the interfacing code in D from the C++ code? 2. If, in your stl example, the default argument could be automatically inferred from the mangling? What I mean is, Do we really need to know the default arguments or are we just having to explicitly use them to make the name mangling work? If it is the latter, then surely couldn't the D compiler sort of have a wild card type of default parameter where the compiler allows any such argument to work? i.e., unless we are actually explicitly needed the default argument in some way it seems that we can just derive it's mangled version from the C++ object data and use that directly in the D mangled version? Essentially the D compiler mangles what it can then substitutes the part of the mangled name in C++ for unknown things into the D mangled name. I just see that if we are linking then why would one have to implement anything? Just essentially Copy the mangling from C++ object data. 3. Hopefully a mapping table is used instead of having to actually have implementations for very compiler? e.g., essentially implement a standard ABI in D, map each C++ compilers mangling version to that instead of implementing each C++ compilers mangling. It seems that 99% of the problem is translation in nature and that one can auto generate D interfaces from C++ mangled names. (in fact, one could go a step further then and simply reverse C++ object code into D code)
Re: Interfacing D to existing C++ code
On Sun, Feb 01, 2015 at 22:32:36 +, Sativa via Digitalmars-d-announce wrote: What I mean is, Do we really need to know the default arguments or are we just having to explicitly use them to make the name mangling work? If it is the latter, then surely couldn't the D compiler sort of have a wild card type of default parameter where the compiler allows any such argument to work? i.e., unless we are actually explicitly needed the default argument in some way it seems that we can just derive it's mangled version from the C++ object data and use that directly in the D mangled version? IIRC, C++ default arguments are handled at compile time and are not part of the ABI. --Ben
Re: Interfacing D to existing C++ code
Thx for the feedback ! bug : https://issues.dlang.org/show_bug.cgi?id=14086 I worked around the name mangling issue with pragmas for now, a new version is available here : https://github.com/gchatelet/dlang_cpp_std/blob/5d52957372f7055b95d4f62ee6d9633bd620a61d/cpp_std.d
Re: Interfacing D to existing C++ code
On Friday, 30 January 2015 at 04:08:56 UTC, Daniel Murphy wrote: Walter Bright wrote in message news:maed4o$2da6$1...@digitalmars.com... So constructors and destructors are mangled 'a la D' instead of the C++ way. Please post this to bugzilla. The problems with constructors go beyond mangling, so the current forced D mangling is intentional to prevent wrong-code bugs. An approach that currently works is porting the code to D, being careful to exactly match the layout and functionality. When done right, this allows templated types to be constructed with any type in either language and passed back and forth without problems. This is what I've done for dmd's ArrayT in ddmd. I've done the same for some matrix ctor of opencv: it's a pain but works... The main problem I've found right now it's that sometime I'm forced to choose a struct in D mapping a class in C++ just to have the right mangling for const ref methods...
Re: Interfacing D to existing C++ code
Walter how far did you get to integrate with the STL ? I started writing std::vector and std::string (linux gcc libstdc++) but maybe someone already made progress on this. It's harder than I thought and will probably require a lot of work to maintain all implementations.
Re: Interfacing D to existing C++ code
On 1/29/15 4:30 AM, Guillaume Chatelet wrote: Walter how far did you get to integrate with the STL ? I started writing std::vector and std::string (linux gcc libstdc++) but maybe someone already made progress on this. It's harder than I thought and will probably require a lot of work to maintain all implementations. Go for it, what we have only proof of concept for now. I know it's difficult, at a point I'll get on to it as well. Maintenance is parallelizable and I trust the community can take care of it. -- Andrei
Re: Interfacing D to existing C++ code
I pushed some code for string here (nothing fancy yet) https://github.com/gchatelet/dlang_cpp_std/blob/master/cpp_std.d The linker complains about missing std::basic_stringchar, std::char_traitschar, std::allocatorchar ::__ctor() where it should be std::basic_stringchar, std::char_traitschar, std::allocatorchar ::basic_string() So constructors and destructors are mangled 'a la D' instead of the C++ way.
Re: Interfacing D to existing C++ code
On 1/29/2015 1:58 PM, Guillaume Chatelet wrote: I pushed some code for string here (nothing fancy yet) https://github.com/gchatelet/dlang_cpp_std/blob/master/cpp_std.d The linker complains about missing std::basic_stringchar, std::char_traitschar, std::allocatorchar ::__ctor() where it should be std::basic_stringchar, std::char_traitschar, std::allocatorchar ::basic_string() So constructors and destructors are mangled 'a la D' instead of the C++ way. Please post this to bugzilla.
Re: Interfacing D to existing C++ code
Walter Bright wrote in message news:maed4o$2da6$1...@digitalmars.com... So constructors and destructors are mangled 'a la D' instead of the C++ way. Please post this to bugzilla. The problems with constructors go beyond mangling, so the current forced D mangling is intentional to prevent wrong-code bugs. An approach that currently works is porting the code to D, being careful to exactly match the layout and functionality. When done right, this allows templated types to be constructed with any type in either language and passed back and forth without problems. This is what I've done for dmd's ArrayT in ddmd.
Re: Interfacing D to existing C++ code
Is it common for a C++ library you want to interface to, to use std library types in its interface? Things like iterators or maybe containers. Do those hit any of the hard cases, so that you'd need to change the std library to resolve the issue?
Re: Interfacing D to existing C++ code
On Friday, 23 January 2015 at 11:04:12 UTC, Walter Bright wrote: Mandatory reddit link: http://www.reddit.com/r/programming/comments/2tdy5z/interfacing_d_to_legacy_c_code_by_walter_bright/ There's been a lot of interest in this topic. Great!
Interfacing D to existing C++ code
Mandatory reddit link: http://www.reddit.com/r/programming/comments/2tdy5z/interfacing_d_to_legacy_c_code_by_walter_bright/ There's been a lot of interest in this topic.
