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.
