I just tried to get this example to work:
https://dlang.org/spec/cpp_interface.html#using_d_classes_from_cpp

It kept crashing for me with a 'privileged instruction' error when the function 'bar' was executed. Finally I removed the call to writefln and voilà it finally works.

So why does it fail? I assumed the standard library functions should all work.
I'm compiling with "dmd -shared -m64 -debug" and link against a C++ DLL that was built with VS2019. Should the D DLL not contain everything to be self-sufficient to use it's entire runtime functionality?
And if not, what other functions might be problematic?

Also, if anyone here has contacts to the people that maintain the samples, maybe someone should adjust the sample to not contain code that may break this way.

On Saturday, 27 March 2021 at 15:09:20 UTC, Jan wrote:
> I just tried to get this example to work:
> https://dlang.org/spec/cpp_interface.html#using_d_classes_from_cpp
>
> It kept crashing for me with a 'privileged instruction' error when the function 'bar' was executed. Finally I removed the call to writefln and voilà it finally works.
>
> So why does it fail? I assumed the standard library functions should all work.
> I'm compiling with "dmd -shared -m64 -debug" and link against a C++ DLL that was built with VS2019. Should the D DLL not contain everything to be self-sufficient to use it's entire runtime functionality?
> And if not, what other functions might be problematic?

The example links objects statically. You may be experiencing additional challenges with crossing DLL boundaries. I have not yet used DLLs, but did you initialise the D runtime?

— Bastiaan.

On Saturday, 27 March 2021 at 18:39:53 UTC, Bastiaan Veelo wrote:

> The example links objects statically. You may be experiencing additional challenges with crossing DLL boundaries. I have not yet used DLLs, but did you initialise the D runtime?
>
> — Bastiaan.

This is an example taken from the documentation. It should work out of the box.

I tried with LDC (don't have dmd on this computer) and I got this error:

/usr/bin/ld: base.o: undefined reference to symbol '_d_allocclass'
/usr/bin/ld: /usr/lib64/libdruntime-ldc-shared.so.90: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status

Given that someone interoperating with C++ probably cares about performance, it should also work out of the box with LDC, or at least tell you the changes that need to be made. I'll open an issue in the bug tracker when I return home (traveling now) if someone else doesn't.

On Saturday, 27 March 2021 at 18:39:53 UTC, Bastiaan Veelo wrote:
> The example links objects statically. You may be experiencing additional challenges with crossing DLL boundaries. I have not yet used DLLs, but did you initialise the D runtime?

I haven't done anything extra (I'm pretty new to D). Do you mean calling this from the D code before using writeln?
https://dlang.org/phobos/core_runtime.html#initialize

I would have thought that happens automatically anyway.

On Saturday, 27 March 2021 at 21:50:19 UTC, Jan wrote:
> On Saturday, 27 March 2021 at 18:39:53 UTC, Bastiaan Veelo wrote:
>> The example links objects statically. You may be experiencing additional challenges with crossing DLL boundaries. I have not yet used DLLs, but did you initialise the D runtime?
>
> I haven't done anything extra (I'm pretty new to D). Do you mean calling this from the D code before using writeln?
> https://dlang.org/phobos/core_runtime.html#initialize
>
> I would have thought that happens automatically anyway.

It should be in this case since the D code in the example is an application with a D main. The compiler will generate an extern(C) main that initializes the runtime and calls your D main. You have to initialize the runtime manually in three cases: you implement an extern(C) main yourself, you use WinMain instead of main, or you implement a shared library in D.

The problem most likely has to do with your use of a DLL rather than linking statically as in the example. D interfaces with C DLLs just fine, but given that C++ compatibility is limited, I would expect issues when interfacing with C++ DLLs.