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](https://dlang.org/blog/2017/08/23/d-as-a-better-c/). 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?
