On Friday, 28 April 2017 at 17:57:34 UTC, Ali Çehreli wrote:
On 04/28/2017 08:56 AM, ParticlePeter wrote:
> C++ Function:
> bool cppFunc( float[3] color );
>
> D binding:
> extern(C++) bool cppFunc( float[3] color );
>
> Using with:
> float[3] my_color;
> cppFunc( my_color );
>
> -> Error: Intern
On Saturday, 29 April 2017 at 01:49:56 UTC, Atila Neves wrote:
On Friday, 28 April 2017 at 18:41:22 UTC, kinke wrote:
On Friday, 28 April 2017 at 18:07:49 UTC, ParticlePeter wrote:
Interesting, your example corresponds to my third case, the
linker error. I am on Window, building an x64 App, afa
On Saturday, 29 April 2017 at 00:31:32 UTC, Nicholas Wilson wrote:
If you are having problems with the linker with Ali's you can do
```
extern(C++) bool cppFunc( float[3] color ); // correct
signature, but causes compiler error
pragma(mangle, cppFunc.mangleof)
float cppFunc(float * color); //
On Saturday, 29 April 2017 at 10:17:47 UTC, Atila Neves wrote:
On Saturday, 29 April 2017 at 06:22:03 UTC, ParticlePeter wrote:
On Saturday, 29 April 2017 at 01:49:56 UTC, Atila Neves wrote:
On Friday, 28 April 2017 at 18:41:22 UTC, kinke wrote:
[...]
The worst part about that is mangling as
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 functi
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 simp
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
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
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
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 GetCurs
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);
Ho
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
101 - 112 of 112 matches
Mail list logo
