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...
Re: std.json questions
On Saturday, 25 April 2015 at 18:30:33 UTC, Baz wrote: On Saturday, 25 April 2015 at 09:56:25 UTC, tired_eyes wrote: I think this is ugly and clunky approach, what is the beautiful one? What you clearly need is a serializer: look at these: http://wiki.dlang.org/Libraries_and_Frameworks#Serialization and also: https://github.com/search?utf8=✓&q=serializer+language%3AD&type=Repositories&ref=searchresults some of them might have an API to save load an object or a struct in a single call. too bad D:YAML links are broken, do you know where to find that project ?
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 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
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 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 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: mscoff x86 invalid pointers
On Saturday, 9 May 2015 at 00:16:28 UTC, Etienne wrote: I'm trying to compile a library that I think used to work with -m32mscoff flag before I reset my machine configurations. https://github.com/etcimon/memutils Whenever I run `dub test --config=32mscoff` it gives me an assertion failure, which is a global variable that already has a pointer value for some reason.. I'm wondering if someone here could test this out on their machine with v2.067.1? There's no reason why this shouldn't work, it runs fine in DMD32/optlink and DMD64/mscoff, just not in DMD32/mscoff. Thanks! you can always use travis-ci to do such a job for you ;)
Object.factory fails for nested classes ?!
Is it a bug or just missing specification that using Object.factory(fullyQualifiedNameToNestedClass) fails ? See repro here: http://dpaste.dzfl.pl/d789237b0f46 Regards, Stephan
Re: Object.factory fails for nested classes ?!
On Sunday, 10 May 2015 at 13:38:22 UTC, extrawurst wrote: Is it a bug or just missing specification that using Object.factory(fullyQualifiedNameToNestedClass) fails ? See repro here: http://dpaste.dzfl.pl/d789237b0f46 Regards, Stephan Ok "real" nested classes (class with outer pointer) wont work (why does it fail inside a struct then?) That still leaves the question why a simple class declared in a unittest scope wont work either (even declared as a static class): http://dpaste.dzfl.pl/33ee48536ecb ideas anyone ?
tharsis.prof tests are broken with dmd 2.068
Hi guys, i am having no luck to fix the bug causing kiith-sa project tharsis.prof to successfully build with unittests: https://github.com/kiith-sa/tharsis.prof/issues/2 the actual compiler error says: ``` C:\_apps\D\dmd2\windows\bin\..\..\src\phobos\std\range\package.d(7180,24): Error: 'tharsis.prof.ranges.__unittestL516_25.SortedRange!(RangeT!(Array!(Z oneData)), __lambda2).SortedRange.dbgVerifySorted' is not nothrow C:\_apps\D\dmd2\windows\bin\..\..\src\phobos\std\algorithm\sorting.d(982,29): Error: template instance tharsis.prof.ranges.__unittestL516_25.assumeSor ted!(__lambda2, RangeT!(Array!(ZoneData))) error instantiating source\tharsis\prof\ranges.d(565,8):instantiated from here: sort!((a, b) => a.duration > b.duration, cast(SwapStrategy)0, RangeT!(Array!(ZoneD ata))) ``` and the code causing this is: ``` auto topLevelArray = Array!ZoneData(topLevel); topLevelArray[].sort!((a, b) => a.duration > b.duration); ```
Re: Mac IDE with Intellisense
On Saturday, 26 September 2015 at 09:17:10 UTC, Mike McKee wrote: I've tried Sublime Text 3 editor on the Mac, but even it doesn't seem to have the D2 language in it yet (only D), and doesn't have intellisense for components in the imports that I do, even after saving the file after adding the import statements. What OSX editor do you recommend that would have intellisense? I use mono-d on win32 and OS X and am happy with it: http://wiki.dlang.org/Mono-D --Stephan
