• wolfiesnotfine (14/14) Feb 05 2021 Hello, I'm currently working on a primarily C++ project but I
• Adam D. Ruppe (19/22) Feb 05 2021 That makes me think it is a static constructor, and indeed there
• wolfiesnotfine (8/11) Feb 05 2021 Hmm. I'm mostly concerned about issues or slowdowns in mixing the
• Bastiaan Veelo (6/10) Feb 05 2021 This being the runtime, I presume it should be called at run time

wolfiesnotfine <aloysuiswolf gmail.com> writes:

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?

Adam D. Ruppe <destructionator gmail.com> writes:

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.

wolfiesnotfine <aloysuiswolf gmail.com> writes:

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.

Bastiaan Veelo <Bastiaan Veelo.net> writes:

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