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.
