Hello, I'm currently working on a primarily C++ project but I wanted to leverage some of D's language features and library for a few parts. I'm using the betterC subset and here's the code snippet in D: https://run.dlang.io/is/XOXF06

It's quite a simple test, and the code just gets called from C++ and I review the stdout. What I've noticed is the print function works fine, however sse() from core.cpuid is incorrectly reporting as false. The function properly returns true if it's not called from C++ but instead a D main function. This makes me think it's related to the GC needing the main function to properly setup, however, I thought the betterC subset was supposed to negate this. While I wanted to make use of more than just cpuid/simd, this was one of the primary things I wanted to put into D code, at least for the moment. any suggestions?

On Friday, 5 February 2021 at 21:04:00 UTC, wolfiesnotfine wrote:
> however sse() from core.cpuid is incorrectly reporting as false. The function properly returns true if it's not called from C++ but instead a D main function.

That makes me think it is a static constructor, and indeed there is one here:

https://github.com/dlang/druntime/blob/master/src/core/cpuid.d#L1068


Static constructors are normally run during druntime initialization, but betterC never uses druntime and thus doesn't initialize it.

You might be able to just call that function directly with some pragma(mangle) hacks (get the symbol name out of the binary, probably something like _D4core5cpuid6__ctor or something along those lines, then declare function like `pragma(mangle, "that name") extern void initCpuId();` and just call it at some point), or copy/paste the source out into your code and call it that way.

The copy/paste is surely easier and more likely to work since even if you get the symbol name, it probably isn't linked in with -betterC since that skips linking the runtime code entirely.


tbh I'd say just don't use betterC, you can still runtime init from C++ and be judicious in what features you use to keep it more minimal.

On Friday, 5 February 2021 at 21:11:20 UTC, Adam D. Ruppe wrote:
> tbh I'd say just don't use betterC, you can still runtime init from C++ and be judicious in what features you use to keep it more minimal.

Hmm. I'm mostly concerned about issues or slowdowns in mixing the manual memory management with GC, as well as the increased binary size of including the GC runtime as I can ultimately just turn the GC off. This is however certainly the better solution. In any case, I'm unsure how I would runtime init from C++. Is there a specific function I should call? Could this be done at compile time in a consteval or constexpr function? Many thanks.

On Friday, 5 February 2021 at 21:40:29 UTC, wolfiesnotfine wrote:
> In any case, I'm unsure how I would runtime init from C++. Is there a specific function I should call?

https://dlang.org/phobos/core_runtime.html#.rt_init

> Could this be done at compile time in a consteval or constexpr function?

This being the runtime, I presume it should be called at run time :-) I haven’t used it, but searching for rt_init should give you some pointers.

—Bastiaan