On Sunday, 5 February 2023 at 00:27:19 UTC, Richard (Rikki) Andrew Cattermole wrote:
> On 05/02/2023 1:20 PM, Adam D Ruppe wrote:
> Even module imports can fail because betterC disables outputting the module data info, even if it would otherwise be required by language rules, despite it not using the druntime.
This only affects you if you use full D to interact with -betterC code.
Even then it is very easy to work around.
https://github.com/Project-Sidero/basic_memory/blob/main/source/sidero/base/moduleinfostubs.d
-betterC DLL's do work with full D executables.
If all you need it for is gluing some stuff together don't listen to Adam about it not working, because it absolutely does and quite usable if you're not expecting there to be a GC.
I'm repeating myself, but I'm very happy to see so many helpful responses to my newbie question. It gives me a good feeling about the community here.
As I wrote, I'd like to use D only in a limited way, for now. My project actually interfaces Python and glib/gstreamer, the glue being provided by my C code. What I'd like to do is to improve on my C code, inspired by this interview. I don't want to introduce another GC or runtime into the picture, and I probably don't need to call any D libraries.
Python -> my C code -> glib/gstreamer C libs
to
Python -> C improved by betterC -> glib/gstreamer C libs
On the surface, betterC seems to be perfect for this case. How would YOU do it (Adam, Richard)?
BtW, gstreamer also has D bindings, and maybe in the future I'll use those. I suspect that Adam's suggestions have a stronger relevance to that case, right?