www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Calling C++ "void foo(Klass&)"

reply Johan Engelen <j j.nl> writes:
Hi all,
   Currently, it is not possible to call the C++ function "void 
foo(Klass&)" when Klass is an extern(C++) _class_ on the D side. 
You have to declare Klass as a D _struct_, otherwise there is no 
way to get the correct mangling. When Klass has virtual 
functions, you're hosed.

For more context (involving "const"), see:
https://forum.dlang.org/post/tvohflgtaxlynpzedqky forum.dlang.org

Is this problem on anybody's radar?
What are the ideas to resolve this issue, or are we content never 
to solve it?

At the very least, we should add information about this to the 
C++ interfacing page, https://dlang.org/spec/cpp_interface.html .

- Johan
Aug 08
parent reply Jacob Carlborg <doob me.com> writes:
On 2017-08-08 20:51, Johan Engelen wrote:
 Hi all,
    Currently, it is not possible to call the C++ function "void
 foo(Klass&)" when Klass is an extern(C++) _class_ on the D side. You
 have to declare Klass as a D _struct_, otherwise there is no way to get
 the correct mangling. When Klass has virtual functions, you're hosed.

 For more context (involving "const"), see:
 https://forum.dlang.org/post/tvohflgtaxlynpzedqky forum.dlang.org

 Is this problem on anybody's radar?
 What are the ideas to resolve this issue, or are we content never to
 solve it?
One way to do it, that might be a bit confusing, is to force the declaration of the function to explicitly specify a pointer or a reference. Currently it looks like it's an implicit pointer. extern (C++) class Klass {} void foo(Klass*); // ok void foo(ref Klass); // ok void foo(Klass); // error Of course, there's always pragma(mangle) as well. -- /Jacob Carlborg
Aug 08
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/8/2017 2:04 PM, Jacob Carlborg wrote:
 On 2017-08-08 20:51, Johan Engelen wrote:
 Hi all,
    Currently, it is not possible to call the C++ function "void
 foo(Klass&)" when Klass is an extern(C++) _class_ on the D side. You
 have to declare Klass as a D _struct_, otherwise there is no way to get
 the correct mangling. When Klass has virtual functions, you're hosed.

 For more context (involving "const"), see:
 https://forum.dlang.org/post/tvohflgtaxlynpzedqky forum.dlang.org

 Is this problem on anybody's radar?
 What are the ideas to resolve this issue, or are we content never to
 solve it?
One way to do it, that might be a bit confusing, is to force the declaration of the function to explicitly specify a pointer or a reference. Currently it looks like it's an implicit pointer. extern (C++) class Klass {} void foo(Klass*); // ok void foo(ref Klass); // ok void foo(Klass); // error Of course, there's always pragma(mangle) as well.
As Jacob hints at, the C++ name mangling for Klass* and Klass& is different. D classes are implicitly by reference. So which mangling to choose? D chose the Klass*. The best way to deal with that is, on the C++ side, add: void foo(Klass* k) { foo(*k); } On a more philosophical note, D makes a hard distinction between struct and class - struct is a value type, class is a reference type. In C++ the characteristics of each can be mixed and matched, not so in D. Interfacing D to such chimera types is going to need a bit of flexibility on the C++ side, such as writing a trampoline like the above.
Aug 09
parent Johan Engelen <j j.nl> writes:
On Wednesday, 9 August 2017 at 18:43:27 UTC, Walter Bright wrote:
 On 8/8/2017 2:04 PM, Jacob Carlborg wrote:
 
 [snip]
 Of course, there's always pragma(mangle) as well.
Yes these work: ``` pragma(mangle, convertMangleToCppRef(g.mangleof)) void g(Klass); pragma(mangle, mangleAsCpp("void Klass::g(Klass&)") void g(Klass); ``` `convertMangleToCppRef` and `mangleAsCpp` are not going to be easy to implement, but perhaps it can be made to work relatively easily for common cases. (hardcoded mangling won't work in a template class) Any takers for a dub package? ;-) On Wednesday, 9 August 2017 at 18:43:27 UTC, Walter Bright wrote:
 As Jacob hints at, the C++ name mangling for Klass* and Klass& 
 is different. D classes are implicitly by reference. So which 
 mangling to choose? D chose the Klass*.
Let's keep this discussion focussed on solutions. We all know what the cause of the problem is.
 The best way to deal with that is, on the C++ side, add:

     void foo(Klass* k) { foo(*k); }
If this is the accepted solution (i.e. don't improve status quo), it means the only way to bind to common C++ libs is to set up a C++ build step for your project. This is already needed for instantiating templated C++ code, so perhaps it's not so bad, but definitely painful if things would have worked easily if only one could annotate things to slightly adjust the C++mangling. Also, automatically generating the trampolines will be a "fun" challenge for a binding tool writer. By the way, UFCS does help nicely for class method trampolines. ``` // C++ class B {}; class A { void foo(B&); }; // in C++ bindings file void foo(A* a, B* b) { a->foo(*b); } ``` ``` // D bindings file extern (C++) class A {} extern (C++) class B {} extern (C++) void foo(A a, B b); // D user code void g(A a, B b) { a.foo(b); } ``` I think this is important information to provide clarity on in the "Interfacing to C++" documentation. -Johan
Aug 14
prev sibling parent reply Mengu <mengukagan gmail.com> writes:
On Tuesday, 8 August 2017 at 21:04:23 UTC, Jacob Carlborg wrote:
 On 2017-08-08 20:51, Johan Engelen wrote:
 Hi all,
    Currently, it is not possible to call the C++ function "void
 foo(Klass&)" when Klass is an extern(C++) _class_ on the D 
 side. You
 have to declare Klass as a D _struct_, otherwise there is no 
 way to get
 the correct mangling. When Klass has virtual functions, you're 
 hosed.

 For more context (involving "const"), see:
 https://forum.dlang.org/post/tvohflgtaxlynpzedqky forum.dlang.org

 Is this problem on anybody's radar?
 What are the ideas to resolve this issue, or are we content 
 never to
 solve it?
One way to do it, that might be a bit confusing, is to force the declaration of the function to explicitly specify a pointer or a reference. Currently it looks like it's an implicit pointer. extern (C++) class Klass {} void foo(Klass*); // ok void foo(ref Klass); // ok void foo(Klass); // error Of course, there's always pragma(mangle) as well.
sorry for hijacking the thread but i have a similar question: i was wondering if i could write a wrapper for a C++11 library called cpr. in one of its header files (https://github.com/whoshuu/cpr/blob/master/include/cpr/auth.h#L13) it has a generic constructor that initializes its member fields. i had no idea as to how to do it. then i came up with the following line: extern (C++, cpr) { this(UT, PT)(ref UT username, ref PT password) { ... } } when i compiled it with the .a lib given, it worked. do you guys think i did it right? the & my second question is: i have no idea what's going on in this file: https://github.com/whoshuu/cpr/blob/master/include/cpr/body.h i'd appreciate some pointers.
Aug 09
parent reply Arjan <arjan ask.me.to> writes:
On Thursday, 10 August 2017 at 00:32:40 UTC, Mengu wrote:
 my second question is: i have no idea what's going on in this 
 file: 
 https://github.com/whoshuu/cpr/blob/master/include/cpr/body.h 
 i'd appreciate some pointers.
A new 'type' named Body which IS-A std::string is defined. To construct a Body there are various options: The ctors 'default': Body(), 'copy': Body(const Body&) and 'move': Body(Body&&) ctors are using the compiler generated default implementation. The same is true for the assignment operators = Then a few explicit conversion ctors are defined to construct a Body from a const char* string and std::string. Explicit means the compiler is not allowed to implicit convert to std::string or const char* for provide args not being a const char* or std::string but for which a conversion exists. Since the h file also contains the definitions, the compiler must inline the code for the Body ctors and assignment operator. It also means not C/cpp file is needed since the function bodies are already in the h file. HTH
Aug 10
parent Mengu <mengukagan gmail.com> writes:
On Thursday, 10 August 2017 at 07:58:55 UTC, Arjan wrote:
 On Thursday, 10 August 2017 at 00:32:40 UTC, Mengu wrote:
 my second question is: i have no idea what's going on in this 
 file: 
 https://github.com/whoshuu/cpr/blob/master/include/cpr/body.h 
 i'd appreciate some pointers.
A new 'type' named Body which IS-A std::string is defined.
i think we can mimic this with an alias this for a string (or const char*) property. is that right?
 To construct a Body there are various options:
 The ctors 'default': Body(), 'copy': Body(const Body&) and 
 'move': Body(Body&&) ctors are using the compiler generated 
 default implementation.
 The same is true for the assignment operators =
how can i check what compiler generates for default so i can add them to my extern C++ clause?
 Then a few explicit conversion ctors are defined to construct a 
 Body from a const char* string and std::string. Explicit means 
 the compiler is not allowed to implicit convert to std::string 
 or const char* for provide args not being a const char* or 
 std::string but for which a conversion exists.
i'll give these converters a try.
 Since the h file also contains the definitions, the compiler 
 must inline the code for the Body ctors and assignment 
 operator. It also means not C/cpp file is needed since the 
 function bodies are already in the h file.
i realized that when i saw the member initialization syntax in header files.
 HTH
thank you very much for the detailed explanation.
Aug 10