Re: C++ interface problem
On Wednesday, 29 April 2015 at 19:04:11 UTC, extrawurst wrote: On Wednesday, 29 April 2015 at 13:55:46 UTC, Benjamin Thaut wrote: On Monday, 27 April 2015 at 21:19:02 UTC, extrawurst wrote: here is the shortened version of the returned class CSteamID: https://gist.github.com/Extrawurst/936f56ceaa87cf287257 this is the shortened interface (no destructors in the rest of the code either): https://gist.github.com/Extrawurst/b20dc5ab84132ecab30d the method `GetFriendByIndex` is the one crashing on win32. I assume that's because CSteamID is returned by value. Are you defining CSteamID in D as a struct? If not you have to because only structs can be returned by value. The next problem is that CSteamID is 64bits wide, this might be a problem as it can not be returned in a single register. You could try changeing the definition of GetFriendByIndex on the D side to ulong GetFriendByIndex(...) and reinterpret the ulong on the D side. If that does not work however you are most likely out of luck because the way your c++ library returns a value type 32-bit is not compatible with what dmd expects. Do you have debug symbols for the third party c++ library? Can you step into the virtual function call to actually see if it ends up in the correct function on the c++ side? Kind Regards Benjamin Thaut Seems i am out of luck. I tried all that. The Steamworks SDK is closed source without debugging symbols. so it wont work.. too bad, this library would have been a good example case of seamless c++-interfacing from D... Did you try windows 64-bit? Calling conventions on 64-bit windows are better standardized.
Re: C++ interface problem
On Thursday, 30 April 2015 at 08:18:16 UTC, Benjamin Thaut wrote: On Wednesday, 29 April 2015 at 19:04:11 UTC, extrawurst wrote: On Wednesday, 29 April 2015 at 13:55:46 UTC, Benjamin Thaut wrote: On Monday, 27 April 2015 at 21:19:02 UTC, extrawurst wrote: here is the shortened version of the returned class CSteamID: https://gist.github.com/Extrawurst/936f56ceaa87cf287257 this is the shortened interface (no destructors in the rest of the code either): https://gist.github.com/Extrawurst/b20dc5ab84132ecab30d the method `GetFriendByIndex` is the one crashing on win32. I assume that's because CSteamID is returned by value. Are you defining CSteamID in D as a struct? If not you have to because only structs can be returned by value. The next problem is that CSteamID is 64bits wide, this might be a problem as it can not be returned in a single register. You could try changeing the definition of GetFriendByIndex on the D side to ulong GetFriendByIndex(...) and reinterpret the ulong on the D side. If that does not work however you are most likely out of luck because the way your c++ library returns a value type 32-bit is not compatible with what dmd expects. Do you have debug symbols for the third party c++ library? Can you step into the virtual function call to actually see if it ends up in the correct function on the c++ side? Kind Regards Benjamin Thaut Seems i am out of luck. I tried all that. The Steamworks SDK is closed source without debugging symbols. so it wont work.. too bad, this library would have been a good example case of seamless c++-interfacing from D... Did you try windows 64-bit? Calling conventions on 64-bit windows are better standardized. no i did not, win64-only is a no-option unfortunately
Re: C++ interface problem
On Wednesday, 29 April 2015 at 13:55:46 UTC, Benjamin Thaut wrote: On Monday, 27 April 2015 at 21:19:02 UTC, extrawurst wrote: here is the shortened version of the returned class CSteamID: https://gist.github.com/Extrawurst/936f56ceaa87cf287257 this is the shortened interface (no destructors in the rest of the code either): https://gist.github.com/Extrawurst/b20dc5ab84132ecab30d the method `GetFriendByIndex` is the one crashing on win32. I assume that's because CSteamID is returned by value. Are you defining CSteamID in D as a struct? If not you have to because only structs can be returned by value. The next problem is that CSteamID is 64bits wide, this might be a problem as it can not be returned in a single register. You could try changeing the definition of GetFriendByIndex on the D side to ulong GetFriendByIndex(...) and reinterpret the ulong on the D side. If that does not work however you are most likely out of luck because the way your c++ library returns a value type 32-bit is not compatible with what dmd expects. Do you have debug symbols for the third party c++ library? Can you step into the virtual function call to actually see if it ends up in the correct function on the c++ side? Kind Regards Benjamin Thaut Seems i am out of luck. I tried all that. The Steamworks SDK is closed source without debugging symbols. so it wont work.. too bad, this library would have been a good example case of seamless c++-interfacing from D...
Re: C++ interface problem
On Monday, 27 April 2015 at 21:19:02 UTC, extrawurst wrote: here is the shortened version of the returned class CSteamID: https://gist.github.com/Extrawurst/936f56ceaa87cf287257 this is the shortened interface (no destructors in the rest of the code either): https://gist.github.com/Extrawurst/b20dc5ab84132ecab30d the method `GetFriendByIndex` is the one crashing on win32. I assume that's because CSteamID is returned by value. Are you defining CSteamID in D as a struct? If not you have to because only structs can be returned by value. The next problem is that CSteamID is 64bits wide, this might be a problem as it can not be returned in a single register. You could try changeing the definition of GetFriendByIndex on the D side to ulong GetFriendByIndex(...) and reinterpret the ulong on the D side. If that does not work however you are most likely out of luck because the way your c++ library returns a value type 32-bit is not compatible with what dmd expects. Do you have debug symbols for the third party c++ library? Can you step into the virtual function call to actually see if it ends up in the correct function on the c++ side? Kind Regards Benjamin Thaut
Re: C++ interface problem
On Monday, 27 April 2015 at 07:37:23 UTC, Laeeth Isharc wrote:
On Sunday, 26 April 2015 at 15:49:46 UTC, extrawurst wrote:
I hope someone can tell me where my bug is.
I am linking to a dynamic library with C++ interfaces:
```
//alias S = ulong;
struct S
{
ulong data;
}
extern(C) I getI();
extern(C++) interface I
{
void foo();
S bar();
}
```
now the question is why does it crash to access bar() in both
cases? (using alias aswell as the struct)
The C++ class S is a POD class (it contains only 64bits of
data and is compiled byte aligned)
The call to bar() from D just crashes on win32, the interface
works fine on osx 64bit.
Any help would be welcome! Is this even possible to solve ? I
have no access to the library code so I am not able to build
the C++ lib with like DMC or something...
Long always 64 bit in D but varies with architecture in C. See
here:
http://wiki.dlang.org/Converting_C_.h_Files_to_D_Modules
Core.stdc.config has alias for the C type that you can use in
place of long.
Thought about that too and tried uint aswell. does not work
either..
Re: C++ interface problem
On Monday, 27 April 2015 at 16:24:16 UTC, Benjamin Thaut wrote:
Am 27.04.2015 um 17:16 schrieb extrawurst:
On Monday, 27 April 2015 at 13:14:21 UTC, Benjamin Thaut wrote:
On Monday, 27 April 2015 at 13:08:33 UTC, extrawurst wrote:
Don't ask me about the compiler, like stated above I have no
control
over the binaries, it is proprietary.
Thats bad to start with.
the C++ class basically is:
```
class S
{
union SteamID_t
{
struct SteamIDComponent_t
{
uint32m_unAccountID : 32;
unsigned intm_unAccountInstance : 20;
unsigned intm_EAccountType : 4;
EUniversem_EUniverse : 8;
} m_comp;
uint64 m_unAll64Bits;
} m_steamid;
}
```
Where is the fuction declaratiosn for bar? If bar is not
virtual you
can not use a extern(C++) Interface. If bar is non-virtual
you have to
use a extern(C++) class.
of course it is all virtual. it is a c++-interface. and
everything works
fine under osx, that would not be the case otherwise, right ?
It depends on the compiler, I don't know the vtbl layout on
OSX. Does the class have a virtual destructor? If you would
post a bit more of S declaration I wouldn't have to guess into
the blue. Not knowing the compiler your third party library was
compiled with doesn't really help either.
Kind Regards
Benjamin
here is the shortened version of the returned class CSteamID:
https://gist.github.com/Extrawurst/936f56ceaa87cf287257
this is the shortened interface (no destructors in the rest of
the code either):
https://gist.github.com/Extrawurst/b20dc5ab84132ecab30d
the method `GetFriendByIndex` is the one crashing on win32.
Re: C++ interface problem
On Sunday, 26 April 2015 at 15:49:46 UTC, extrawurst wrote:
I hope someone can tell me where my bug is.
I am linking to a dynamic library with C++ interfaces:
```
//alias S = ulong;
struct S
{
ulong data;
}
extern(C) I getI();
extern(C++) interface I
{
void foo();
S bar();
}
```
now the question is why does it crash to access bar() in both
cases? (using alias aswell as the struct)
The C++ class S is a POD class (it contains only 64bits of data
and is compiled byte aligned)
The call to bar() from D just crashes on win32, the interface
works fine on osx 64bit.
Any help would be welcome! Is this even possible to solve ? I
have no access to the library code so I am not able to build
the C++ lib with like DMC or something...
Long always 64 bit in D but varies with architecture in C. See
here:
http://wiki.dlang.org/Converting_C_.h_Files_to_D_Modules
Core.stdc.config has alias for the C type that you can use in
place of long.
Re: C++ interface problem
On Monday, 27 April 2015 at 13:08:33 UTC, extrawurst wrote:
Don't ask me about the compiler, like stated above I have no
control over the binaries, it is proprietary.
Thats bad to start with.
the C++ class basically is:
```
class S
{
union SteamID_t
{
struct SteamIDComponent_t
{
uint32 m_unAccountID : 32;
unsigned intm_unAccountInstance : 20;
unsigned intm_EAccountType : 4;
EUniverse m_EUniverse : 8;
} m_comp;
uint64 m_unAll64Bits;
} m_steamid;
}
```
Where is the fuction declaratiosn for bar? If bar is not virtual
you can not use a extern(C++) Interface. If bar is non-virtual
you have to use a extern(C++) class.
Re: C++ interface problem
On Monday, 27 April 2015 at 11:00:23 UTC, extrawurst wrote: Thought about that too and tried uint aswell. does not work either.. Please post the c++ declarations as well. Which c++ compiler do you use for win32? (dmc or msvc) Kind Regards Benjamin
Re: C++ interface problem
On Monday, 27 April 2015 at 12:56:57 UTC, Benjamin Thaut wrote:
On Monday, 27 April 2015 at 11:00:23 UTC, extrawurst wrote:
Thought about that too and tried uint aswell. does not work
either..
Please post the c++ declarations as well. Which c++ compiler do
you use for win32? (dmc or msvc)
Kind Regards
Benjamin
Don't ask me about the compiler, like stated above I have no
control over the binaries, it is proprietary.
the C++ class basically is:
```
class S
{
union SteamID_t
{
struct SteamIDComponent_t
{
uint32 m_unAccountID : 32;
unsigned intm_unAccountInstance : 20;
unsigned intm_EAccountType : 4;
EUniverse m_EUniverse : 8;
} m_comp;
uint64 m_unAll64Bits;
} m_steamid;
}
```
Re: C++ interface problem
On Monday, 27 April 2015 at 13:14:21 UTC, Benjamin Thaut wrote:
On Monday, 27 April 2015 at 13:08:33 UTC, extrawurst wrote:
Don't ask me about the compiler, like stated above I have no
control over the binaries, it is proprietary.
Thats bad to start with.
the C++ class basically is:
```
class S
{
union SteamID_t
{
struct SteamIDComponent_t
{
uint32 m_unAccountID : 32;
unsigned intm_unAccountInstance : 20;
unsigned intm_EAccountType : 4;
EUniverse m_EUniverse : 8;
} m_comp;
uint64 m_unAll64Bits;
} m_steamid;
}
```
Where is the fuction declaratiosn for bar? If bar is not
virtual you can not use a extern(C++) Interface. If bar is
non-virtual you have to use a extern(C++) class.
of course it is all virtual. it is a c++-interface. and
everything works fine under osx, that would not be the case
otherwise, right ?
Re: C++ interface problem
Am 27.04.2015 um 17:16 schrieb extrawurst:
On Monday, 27 April 2015 at 13:14:21 UTC, Benjamin Thaut wrote:
On Monday, 27 April 2015 at 13:08:33 UTC, extrawurst wrote:
Don't ask me about the compiler, like stated above I have no control
over the binaries, it is proprietary.
Thats bad to start with.
the C++ class basically is:
```
class S
{
union SteamID_t
{
struct SteamIDComponent_t
{
uint32m_unAccountID : 32;
unsigned intm_unAccountInstance : 20;
unsigned intm_EAccountType : 4;
EUniversem_EUniverse : 8;
} m_comp;
uint64 m_unAll64Bits;
} m_steamid;
}
```
Where is the fuction declaratiosn for bar? If bar is not virtual you
can not use a extern(C++) Interface. If bar is non-virtual you have to
use a extern(C++) class.
of course it is all virtual. it is a c++-interface. and everything works
fine under osx, that would not be the case otherwise, right ?
It depends on the compiler, I don't know the vtbl layout on OSX. Does
the class have a virtual destructor? If you would post a bit more of S
declaration I wouldn't have to guess into the blue. Not knowing the
compiler your third party library was compiled with doesn't really help
either.
Kind Regards
Benjamin
C++ interface problem
I hope someone can tell me where my bug is.
I am linking to a dynamic library with C++ interfaces:
```
//alias S = ulong;
struct S
{
ulong data;
}
extern(C) I getI();
extern(C++) interface I
{
void foo();
S bar();
}
```
now the question is why does it crash to access bar() in both
cases? (using alias aswell as the struct)
The C++ class S is a POD class (it contains only 64bits of data
and is compiled byte aligned)
The call to bar() from D just crashes on win32, the interface
works fine on osx 64bit.
Any help would be welcome! Is this even possible to solve ? I
have no access to the library code so I am not able to build the
C++ lib with like DMC or something...
