37 ms·
That page specifies a rationale of: code loaded from C will not load the D runtime. Is it also possible to provide a C-callable shared D library that initialize
by asveikau 4y ago
That page specifies a rationale of: code loaded from C will not load the D runtime. Is it also possible to provide a C-callable shared D library that initializes the runtime dynamically? Would you then get some missing features like global constructors?
Googling around seems to suggest there is rt_init or Runtime.initialize for that?
I've never used D, I'm just curious about the problem described.
Ps. Goes without saying that i, like others, appreciate your comments here.
- WalterBright 4y agoThe impetus for DasBetterC is to use a subset of D that does not require the D runtime library. A surprising amount of D users like this and use it. I use it for projects where I want a small runtime executable. DasBetterC executables are as small as C ones can be.
- lwswl 4y agoAre they really? Because most c executables are almost never as small as they can be.
- mhh__ 4y agoIf the D code is aware that it needs to initialize the runtime then yes, either that you or you initialize it yourself before using it. rt_init will fire up the D runtime. As for constructors the runtime should handle those when the module is initialised, so not necessarily on program start up or the DSO being loaded. If, however, you want to register a C runtime constructor you can do do so with pragma(crt_constructor). I actually recently-ish fixed a bug to make the aforementioned type of constructor work on MacOS because Apple decided to deprecate them with no reason.