www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - C++ binding issues with C++ function returning a simple POD struct.

reply ParticlePeter <ParticlePeter gmx.de> writes:
I am statically linking to ImGui [1] on Win 10 x64, quite 
successfully till this issue came up. The noticed error so far 
comes when an ImGui function returns an ImVec2, a simple POD 
struct of two float members. I can use this struct as argument to 
functions but when it is returned from a function I get a 
0xC0000005: Access violation reading location 0xFFFFFFFFFFFFFFFF. 
I can even debug the process with Visual Studion, mixed d and c++ 
sources. The functions I tested return data from some internal 
global ImGui data, which I can fully examine, the crash happens 
on the return statement. Moreover, some functions have variations 
which return only one component from that ImVec2 POD, which do 
work as expected, e.g.:

     ImVec2          GetCursorPos();   // crash
     float           GetCursorPosX();  // works
     float           GetCursorPosY();  // works

The latter do basically the same as the first one, but return 
ImVec.x or .y respectively.

How could I further debug this?
If somebody would be willing to look at the source, the binding 
is here [2].


[1] https://github.com/ocornut/imgui
[2] https://github.com/ParticlePeter/imgui_lib
May 21
next sibling parent reply Stefan Koch <uplink.coder googlemail.com> writes:
On Sunday, 21 May 2017 at 19:33:06 UTC, ParticlePeter wrote:
 I am statically linking to ImGui [1] on Win 10 x64, quite 
 successfully till this issue came up. The noticed error so far 
 comes when an ImGui function returns an ImVec2, a simple POD 
 struct of two float members. I can use this struct as argument 
 to functions but when it is returned from a function I get a 
 0xC0000005: Access violation reading location 
 0xFFFFFFFFFFFFFFFF. I can even debug the process with Visual 
 Studion, mixed d and c++ sources. The functions I tested return 
 data from some internal global ImGui data, which I can fully 
 examine, the crash happens on the return statement. Moreover, 
 some functions have variations which return only one component 
 from that ImVec2 POD, which do work as expected, e.g.:

 [...]
are you aware of https://github.com/Extrawurst/DerelictImgui ?
May 21
next sibling parent ParticlePeter <ParticlePeter gmx.de> writes:
On Sunday, 21 May 2017 at 19:58:32 UTC, Stefan Koch wrote:
 On Sunday, 21 May 2017 at 19:33:06 UTC, ParticlePeter wrote:
 I am statically linking to ImGui [1] on Win 10 x64, quite 
 successfully till this issue came up. The noticed error so far 
 comes when an ImGui function returns an ImVec2, a simple POD 
 struct of two float members. I can use this struct as argument 
 to functions but when it is returned from a function I get a 
 0xC0000005: Access violation reading location 
 0xFFFFFFFFFFFFFFFF. I can even debug the process with Visual 
 Studion, mixed d and c++ sources. The functions I tested 
 return data from some internal global ImGui data, which I can 
 fully examine, the crash happens on the return statement. 
 Moreover, some functions have variations which return only one 
 component from that ImVec2 POD, which do work as expected, 
 e.g.:

 [...]
are you aware of https://github.com/Extrawurst/DerelictImgui ?
Yes I am, its (understandably) not being updated too regularly, it goes the route of creating a C binding, and a D binding on top, lot of work. We should be able to bind the C++ variant directly by now I think.
May 21
prev sibling parent reply Jerry <hurricane hereiam.com> writes:
On Sunday, 21 May 2017 at 19:58:32 UTC, Stefan Koch wrote:
 On Sunday, 21 May 2017 at 19:33:06 UTC, ParticlePeter wrote:
 I am statically linking to ImGui [1] on Win 10 x64, quite 
 successfully till this issue came up. The noticed error so far 
 comes when an ImGui function returns an ImVec2, a simple POD 
 struct of two float members. I can use this struct as argument 
 to functions but when it is returned from a function I get a 
 0xC0000005: Access violation reading location 
 0xFFFFFFFFFFFFFFFF. I can even debug the process with Visual 
 Studion, mixed d and c++ sources. The functions I tested 
 return data from some internal global ImGui data, which I can 
 fully examine, the crash happens on the return statement. 
 Moreover, some functions have variations which return only one 
 component from that ImVec2 POD, which do work as expected, 
 e.g.:

 [...]
are you aware of https://github.com/Extrawurst/DerelictImgui ?
Not everyone likes the set of 'derelict' libraries. Especially if you need to statically link to a library.
May 22
parent Mike Parker <aldacron gmail.com> writes:
On Monday, 22 May 2017 at 14:11:35 UTC, Jerry wrote:

 are you aware of https://github.com/Extrawurst/DerelictImgui ?
Not everyone likes the set of 'derelict' libraries. Especially if you need to statically link to a library.
Some of the Derelict packages in the DerelictOrg repo (the SDL2, GLFW3, and OpenAL bindings off the top of my head -- maybe DerelictPQ as well) support static linking now by either specifying a dub configuration or a -version on the command line. That number will eventually increase.
May 22
prev sibling next sibling parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Sunday, 21 May 2017 at 19:33:06 UTC, ParticlePeter wrote:
 I am statically linking to ImGui [1] on Win 10 x64, quite 
 successfully till this issue came up. The noticed error so far 
 comes when an ImGui function returns an ImVec2, a simple POD 
 struct of two float members. I can use this struct as argument 
 to functions but when it is returned from a function I get a 
 0xC0000005: Access violation reading location 
 0xFFFFFFFFFFFFFFFF. I can even debug the process with Visual 
 Studion, mixed d and c++ sources. The functions I tested return 
 data from some internal global ImGui data, which I can fully 
 examine, the crash happens on the return statement. Moreover, 
 some functions have variations which return only one component 
 from that ImVec2 POD, which do work as expected, e.g.:

     ImVec2          GetCursorPos();   // crash
     float           GetCursorPosX();  // works
     float           GetCursorPosY();  // works

 The latter do basically the same as the first one, but return 
 ImVec.x or .y respectively.

 How could I further debug this?
 If somebody would be willing to look at the source, the binding 
 is here [2].


 [1] https://github.com/ocornut/imgui
 [2] https://github.com/ParticlePeter/imgui_lib
Probably because the D side is expecting to have the struct returned in a pointer allocated by the callee and then the C++ puts it in regs and BOOM. If you wrap the C++ side to return the struct by a pointer then use that in D, then it should work.
May 21
next sibling parent reply evilrat <evilrat666 gmail.com> writes:
On Monday, 22 May 2017 at 01:27:22 UTC, Nicholas Wilson wrote:
 On Sunday, 21 May 2017 at 19:33:06 UTC, ParticlePeter wrote:
 I am statically linking to ImGui [1] on Win 10 x64, quite 
 successfully till this issue came up. The noticed error so far 
 comes when an ImGui function returns an ImVec2, a simple POD 
 struct of two float members. I can use this struct as argument 
 to functions but when it is returned from a function I get a 
 0xC0000005: Access violation reading location 
 0xFFFFFFFFFFFFFFFF. I can even debug the process with Visual 
 Studion, mixed d and c++ sources. The functions I tested 
 return data from some internal global ImGui data, which I can 
 fully examine, the crash happens on the return statement. 
 Moreover, some functions have variations which return only one 
 component from that ImVec2 POD, which do work as expected, 
 e.g.:

     ImVec2          GetCursorPos();   // crash
     float           GetCursorPosX();  // works
     float           GetCursorPosY();  // works

 The latter do basically the same as the first one, but return 
 ImVec.x or .y respectively.

 How could I further debug this?
 If somebody would be willing to look at the source, the 
 binding is here [2].


 [1] https://github.com/ocornut/imgui
 [2] https://github.com/ParticlePeter/imgui_lib
Probably because the D side is expecting to have the struct returned in a pointer allocated by the callee and then the C++ puts it in regs and BOOM. If you wrap the C++ side to return the struct by a pointer then use that in D, then it should work.
And this is actually D problem. In fact first bug report on this thing was dated back to 2014. Still not fixed. There is possible hacky workaround to try - put struct as pointer arg instead of return and make helper method to use it, like this -------- HACK ------------------- // extern(C++) of course void GetCursorPos(ImVec2* v); // helper ImVec2 GetCursorPos() { ImVec2 temp; GetCursorPos(&temp); return temp; } ----------------------------------
May 21
parent reply ParticlePeter <ParticlePeter gmx.de> writes:
On Monday, 22 May 2017 at 01:39:04 UTC, evilrat wrote:
 On Monday, 22 May 2017 at 01:27:22 UTC, Nicholas Wilson wrote:
 Probably because the D side is expecting to have the struct 
 returned in a pointer allocated by the callee and then the C++ 
 puts it in regs and BOOM.

 If you wrap the C++ side to return the struct by a pointer 
 then use that in D, then it should work.
And this is actually D problem. In fact first bug report on this thing was dated back to 2014. Still not fixed.
Thanks for your reply, do you have any links to some bug report of that issue?
 There is possible hacky workaround to try - put struct as 
 pointer arg instead of return and make helper method to use it, 
 like this

 -------- HACK -------------------
 // extern(C++) of course
 void GetCursorPos(ImVec2* v);

 // helper
 ImVec2 GetCursorPos()
 {
  ImVec2 temp;
  GetCursorPos(&temp);
  return temp;
 }
 ----------------------------------
Actually, your example would work just fine, my problem and possible solution is the other way around :-). First I'll try to force a copy with a wrapper func and same sig.
May 21
parent reply evilrat <evilrat666 gmail.com> writes:
On Monday, 22 May 2017 at 06:33:37 UTC, ParticlePeter wrote:
 On Monday, 22 May 2017 at 01:39:04 UTC, evilrat wrote:
 And this is actually D problem. In fact first bug report on 
 this thing was dated back to  2014. Still not fixed.
Thanks for your reply, do you have any links to some bug report of that issue?
Just search for "c++ struct" https://issues.dlang.org/buglist.cgi?quicksearch=c%2B%2B%20struct https://issues.dlang.org/show_bug.cgi?id=13207 https://issues.dlang.org/show_bug.cgi?id=16527
 Actually, your example would work just fine, my problem and 
 possible solution is the other way around :-). First I'll try 
 to force a copy with a wrapper func and same sig.
You mean from D to C++? Well, that sucks.
May 22
parent reply ParticlePeter <ParticlePeter gmx.de> writes:
On Monday, 22 May 2017 at 07:24:20 UTC, evilrat wrote:
 On Monday, 22 May 2017 at 06:33:37 UTC, ParticlePeter wrote:
 On Monday, 22 May 2017 at 01:39:04 UTC, evilrat wrote:
 And this is actually D problem. In fact first bug report on 
 this thing was dated back to  2014. Still not fixed.
Thanks for your reply, do you have any links to some bug report of that issue?
Just search for "c++ struct" https://issues.dlang.org/buglist.cgi?quicksearch=c%2B%2B%20struct https://issues.dlang.org/show_bug.cgi?id=13207 https://issues.dlang.org/show_bug.cgi?id=16527
That's really old, and of essential requirement I would assume. Thanks, I will comment the bug.
 Actually, your example would work just fine, my problem and 
 possible solution is the other way around :-). First I'll try 
 to force a copy with a wrapper func and same sig.
You mean from D to C++? Well, that sucks.
No, no, this (other) way around :-), still C++ to D. It actually works btw: -------- HACK ------------------- // original C++ ImVec2 GetCursorPos(); // C++ helper void GetCursorPos(ImVec2& result) { result = GetCursorPos(); } // bind with extern(C++) void GetCursorPos(ref ImVec2 result); ----------------------------------
May 22
parent reply evilrat <evilrat666 gmail.com> writes:
On Monday, 22 May 2017 at 08:03:07 UTC, ParticlePeter wrote:
 No, no, this (other) way around :-), still C++ to D. It 
 actually works btw:

 -------- HACK -------------------
 // original C++
 ImVec2 GetCursorPos();

 // C++ helper
 void GetCursorPos(ImVec2& result) {
   result = GetCursorPos();
 }

 // bind with
 extern(C++)
 void GetCursorPos(ref ImVec2 result);
 ----------------------------------
My proposed hack is purely D side though O_-
May 22
parent reply ParticlePeter <ParticlePeter gmx.de> writes:
On Monday, 22 May 2017 at 08:25:45 UTC, evilrat wrote:
 On Monday, 22 May 2017 at 08:03:07 UTC, ParticlePeter wrote:
 No, no, this (other) way around :-), still C++ to D. It 
 actually works btw:

 -------- HACK -------------------
 // original C++
 ImVec2 GetCursorPos();

 // C++ helper
 void GetCursorPos(ImVec2& result) {
   result = GetCursorPos();
 }

 // bind with
 extern(C++)
 void GetCursorPos(ref ImVec2 result);
 ----------------------------------
My proposed hack is purely D side though O_-
Then I am not getting your hack, this function here, does not exist on the C++ side. -------- HACK ------------------- // extern(C++) of course void GetCursorPos(ImVec2* v); How is it supposed to work then if there is no definition?
May 22
parent reply evilrat <evilrat666 gmail.com> writes:
On Monday, 22 May 2017 at 11:25:31 UTC, ParticlePeter wrote:
 Then I am not getting your hack, this function here, does not 
 exist on the C++ side.
 -------- HACK -------------------
 // extern(C++) of course
 void GetCursorPos(ImVec2* v);

 How is it supposed to work then if there is no definition?
you "forge" this signature insted of correct one, I suggest also wrap it some handy version in case this is "suddenly got working" version (PROPER_ABI) { extern(C++) ImVec2 GetCursorPos(); } else // hacky one { extern(C++) void GetCursorPos(ImVec2* v); ... put helper here to match excepted API, in case of C++ class add it to the end as 'final'... } This works because it matches name mangling on this one. And even if its not it is possible to hammer it in with pragma mangle.
May 22
parent ParticlePeter <ParticlePeter gmx.de> writes:
On Monday, 22 May 2017 at 13:03:17 UTC, evilrat wrote:
 On Monday, 22 May 2017 at 11:25:31 UTC, ParticlePeter wrote:
 Then I am not getting your hack, this function here, does not 
 exist on the C++ side.
 -------- HACK -------------------
 // extern(C++) of course
 void GetCursorPos(ImVec2* v);

 How is it supposed to work then if there is no definition?
you "forge" this signature insted of correct one, I suggest also wrap it some handy version in case this is "suddenly got working" version (PROPER_ABI) { extern(C++) ImVec2 GetCursorPos(); } else // hacky one { extern(C++) void GetCursorPos(ImVec2* v); ... put helper here to match excepted API, in case of C++ class add it to the end as 'final'... } This works because it matches name mangling on this one. And even if its not it is possible to hammer it in with pragma mangle.
Never stop learning, that actually works! But only with the pragma mangle hammer. Nice, but again some more mangle pragmas. The better way seems to be Jerry's suggestion, works as well, see bellow.
May 22
prev sibling parent ParticlePeter <ParticlePeter gmx.de> writes:
On Monday, 22 May 2017 at 01:27:22 UTC, Nicholas Wilson wrote:
 On Sunday, 21 May 2017 at 19:33:06 UTC, ParticlePeter wrote:
 I am statically linking to ImGui [1] on Win 10 x64, quite 
 successfully till this issue came up. The noticed error so far 
 comes when an ImGui function returns an ImVec2, a simple POD 
 struct of two float members. I can use this struct as argument 
 to functions but when it is returned from a function I get a 
 0xC0000005: Access violation reading location 
 0xFFFFFFFFFFFFFFFF. I can even debug the process with Visual 
 Studion, mixed d and c++ sources. The functions I tested 
 return data from some internal global ImGui data, which I can 
 fully examine, the crash happens on the return statement. 
 Moreover, some functions have variations which return only one 
 component from that ImVec2 POD, which do work as expected, 
 e.g.:

     ImVec2          GetCursorPos();   // crash
     float           GetCursorPosX();  // works
     float           GetCursorPosY();  // works

 The latter do basically the same as the first one, but return 
 ImVec.x or .y respectively.

 How could I further debug this?
 If somebody would be willing to look at the source, the 
 binding is here [2].


 [1] https://github.com/ocornut/imgui
 [2] https://github.com/ParticlePeter/imgui_lib
Probably because the D side is expecting to have the struct returned in a pointer allocated by the callee and then the C++ puts it in regs and BOOM.
Thanks for your reply, but that would be wired. The function signature clearly tells me: I am returning a (copy of a) ImVec2 on the stack. How could D expect any kind of pointer in that case? And should that not be true for the variants returning float as well? Almost same signature. But I agree with enhanced fishiness happening in the interface.
 If you wrap the C++ side to return the struct by a pointer then 
 use that in D, then it should work.
I've hoped to avoid extra work other then translating the header, but now I fear it won't. I'll give it a try.
May 21
prev sibling next sibling parent reply Jerry <hurricane hereiam.com> writes:
On Sunday, 21 May 2017 at 19:33:06 UTC, ParticlePeter wrote:
 I am statically linking to ImGui [1] on Win 10 x64, quite 
 successfully till this issue came up. The noticed error so far 
 comes when an ImGui function returns an ImVec2, a simple POD 
 struct of two float members. I can use this struct as argument 
 to functions but when it is returned from a function I get a 
 0xC0000005: Access violation reading location 
 0xFFFFFFFFFFFFFFFF. I can even debug the process with Visual 
 Studion, mixed d and c++ sources. The functions I tested return 
 data from some internal global ImGui data, which I can fully 
 examine, the crash happens on the return statement. Moreover, 
 some functions have variations which return only one component 
 from that ImVec2 POD, which do work as expected, e.g.:

     ImVec2          GetCursorPos();   // crash
     float           GetCursorPosX();  // works
     float           GetCursorPosY();  // works

 The latter do basically the same as the first one, but return 
 ImVec.x or .y respectively.

 How could I further debug this?
 If somebody would be willing to look at the source, the binding 
 is here [2].


 [1] https://github.com/ocornut/imgui
 [2] https://github.com/ParticlePeter/imgui_lib
IIRC the problem is that it isn't a POD type. ImVec2 has its own default constructor. The problem now is that because it no longer is POD, Window's ABI handles it different and doesn't put the value in a register. Now with D is that you aren't allowed to specify your own default constructor, so there's no equivalent way for it to know that it isn't a POD. A way around this is to specify your own destructor or copy constructor in the D ImVec2. I forget what the rules are for it, but I think that should do it.
May 22
parent reply ParticlePeter <ParticlePeter gmx.de> writes:
On Monday, 22 May 2017 at 14:01:56 UTC, Jerry wrote:

 IIRC the problem is that it isn't a POD type. ImVec2 has its 
 own default constructor. The problem now is that because it no 
 longer is POD, Window's ABI handles it different and doesn't 
 put the value in a register. Now with D is that you aren't 
 allowed to specify your own default constructor, so there's no 
 equivalent way for it to know that it isn't a POD. A way around 
 this is to specify your own destructor or copy constructor in 
 the D ImVec2. I forget what the rules are for it, but I think 
 that should do it.
Thanks, with any of them, ~this or this(this) (both can be empty), the functions work as expected, nice. Also replying your next post, extern(C++) is on for the whole module: https://github.com/ParticlePeter/imgui_lib/blob/master/source/imgui/types.d#L39 but I learned how to link to github lines from your post :-)
May 22
parent evilrat <evilrat666 gmail.com> writes:
On Monday, 22 May 2017 at 18:51:43 UTC, ParticlePeter wrote:
 On Monday, 22 May 2017 at 14:01:56 UTC, Jerry wrote:

 IIRC the problem is that it isn't a POD type. ImVec2 has its 
 own default constructor. The problem now is that because it no 
 longer is POD, Window's ABI handles it different and doesn't 
 put the value in a register. Now with D is that you aren't 
 allowed to specify your own default constructor, so there's no 
 equivalent way for it to know that it isn't a POD. A way 
 around this is to specify your own destructor or copy 
 constructor in the D ImVec2. I forget what the rules are for 
 it, but I think that should do it.
Thanks, with any of them, ~this or this(this) (both can be empty), the functions work as expected, nice. Also replying your next post, extern(C++) is on for the whole module: https://github.com/ParticlePeter/imgui_lib/blob/master/source/imgui/types.d#L39 but I learned how to link to github lines from your post :-)
Better check if empty postblit('this(this)' ctor) works well when assign structs though. It would be annoying if passing and assigning structs on D side would do something weird. And, if it works I should probably do this for DirectX bindings as well instead of hack.
May 22
prev sibling parent Jerry <hurricane hereiam.com> writes:
Note that you also probably need extern(C++) on the struct ImVec2.

https://github.com/ParticlePeter/imgui_lib/blob/master/source/imgui/types.d#L84
May 22