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?

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.

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.

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

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.

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.

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.

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 :-)

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.