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...

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.

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..

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

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 int		m_unAccountInstance : 20;
			unsigned int		m_EAccountType : 4;
			EUniverse			m_EUniverse : 8;
		} m_comp;

		uint64 m_unAll64Bits;
	} m_steamid;
}
```

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 int		m_unAccountInstance : 20;
> 			unsigned int		m_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.

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 int		m_unAccountInstance : 20;
>> 			unsigned int		m_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 ?

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
>>>         {
>>>             uint32                m_unAccountID : 32;
>>>             unsigned int        m_unAccountInstance : 20;
>>>             unsigned int        m_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 ?

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

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
>>>>        {
>>>>            uint32                m_unAccountID : 32;
>>>>            unsigned int        m_unAccountInstance : 20;
>>>>            unsigned int        m_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 ?
>
> 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.

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