Dear BindBC users,

I am conducting an informal survey on the forums here to gauge the impact of the project's wide adoption of automatic code-generation via string mixins over the past 4 years.

If you depend on one or more BindBC libraries in your project, then I would love if you could fill out your answers to the following questions, particularly noting which specific libraries affected your answers & when you had this experience. Your answers will help inform what direction I take for the future of the BindBC project's code.

1. What BindBC libraries do your projects depend on, and to what extent do you rely on them?

2. Have you ever experienced any usability issues caused by the automatic code-generation in a BindBC library?

3. Have you ever found that a BindBC library took a long time to compile?

On Saturday, 23 August 2025 at 15:35:30 UTC, IchorDev wrote:

1. bindbc-allegro5, and bindbc-physfs
2. Haven't noticed any issues. Hmmm maybe optional parentheses don't appear to be optionally anymore? I noticed this going from SiegeLord/DAllegro5 to bindbc-allegro5.
3. No

Not sure if this is helpful at all, but anyway...

Jordan

1. bindbc-sdl
2. No, however bindbc always build in separate packages even --combined, not sure why.
3. Not remakerd anything. Of course more speed is always appreciated.

On Saturday, 23 August 2025 at 20:53:47 UTC, Jordan Wilson wrote:

Unfortunately these are unofficial packages that I have no direct control over.

That would be because you are using dynamic bindings. bindbc-allegro5 doesn't wrap its function pointers in a regular function (most official BindBC libraries do this now), and functions vs function pointers have incompatible call/reference syntax:

int fn(){} //a function
int function() fnPtr; //a function pointer

int a1 = fn();
int a2 = fnPtr();

int b1 = fn;
int function() b2 = fnPtr;

int function() c1 = &fn;
int function()* c2 = &fnPtr;

SiegeLord/DAllegro5 only has static bindings, but bindbc-allegro5 defaults to using dynamic bindings. For most use-cases static bindings are simpler. Dynamic bindings are useful when you seriously need to re-link libraries at runtime (i.e. basically never), or want more control over 'missing library' error messages for a better end-user experience.

On Saturday, 23 August 2025 at 20:53:47 UTC, Jordan Wilson wrote:

Unfortunately these are unofficial packages that I have no direct control over.

That would be because you are using dynamic bindings. bindbc-allegro5 doesn't wrap its function pointers in a regular function (most official BindBC libraries do this now), and functions vs function pointers have incompatible call/reference syntax:

int fn(){} //a function
int function() fnPtr; //a function pointer

int a1 = fn();
int a2 = fnPtr();

int b1 = fn;
int function() b2 = fnPtr;

int function() c1 = &fn;
int function()* c2 = &fnPtr;

SiegeLord/DAllegro5 only has static bindings, but bindbc-allegro5 defaults to using dynamic bindings. For most use-cases static bindings are simpler. Dynamic bindings are useful when you seriously need to re-link libraries at runtime (i.e. basically never), or want more control over 'missing library' error messages for a better end-user experience.

On Saturday, 23 August 2025 at 15:35:30 UTC, IchorDev wrote:

1. bindbc-opengl is the only remaining dependency, used to use bindbc for all bindings, moved away.
2. Poor to no documentation, constant version incompatibilities, slower compile times and overall difficult to inspect code lead me to drop bindbc.
3. Yes, mainly bindbc-opengl, though some of this was due to compiler quirks. However the other usability issues are mainly what made me drop it.

On Saturday, 23 August 2025 at 15:35:30 UTC, IchorDev wrote:

bindbc.sdl and bindbc.opengl (and I by extension, bindbc.loader). I've been using these for teaching students graphics and games courses on windows, linux, and mac.

Not so far.

I haven't profiled, so it's been fast enough for the smaller scale projects I've worked on.

On Monday, 25 August 2025 at 17:22:40 UTC, Mike Shah wrote:

Oh hey, that sounds awesome!

On Monday, 25 August 2025 at 13:01:08 UTC, Luna wrote:

What kind of documentation would there be?
If you mean documentation from the original project the bindings are for, then this is simply infeasible due to requiring an astronomical amount of time to convert, and the potential for documentation to be different between versions, etc.

Could you please elaborate on these two?