On Tuesday, 12 January 2016 at 21:10:28 UTC, John Colvin wrote:
On Tuesday, 12 January 2016 at 20:32:57 UTC, jmh530 wrote:
I'm not sure when you would want to use dynamic bindings.
When you want to have control over the process of loading a
library e.g. if you want it to be an optional dependency at
For me, the big benefit is that it eliminates the link-time
dependency on the C library. I don't have to worry about whether
the dev package is installed on Linux, or the COFF/OMF issues on
Windows. Reducing dependencies like this makes avoids several
potential build issues, something particularly good for open
source projects. You can download the source for an SDL-based
game, for example, and not worry about which version of the SDL
development libraries you need to build it.
Another benefit is that the app doesn't need to fail if a
particular version of a library is not available. For example,
DerelictUtil, the library which provides the loader for all of
the Derelict bindings, allows the ability to continue loading if
certain functions are missing. You can choose to use those
functions if present and fallback on something else if they
aren't. If you've ever used OpenGL, you're probably already doing
this. You can use version 4.x if it's available and fallback to
3.x if it isn't; extensions are loaded on an as-needed and
as-available basis. A dynamic binding allows this sort of
behavior with any library.
One of the entries in, IIRC, Game Programming Gems 2, talked
about solving the DLL Hell problem with dynamic loading. For me,
it really just boils down to more convenient builds. I tend to
prefer it over static or dynamic linking. In fact, dynamic
linking doesn't even enter the picture for me in D. If I need a
shared library, I'll just load it myself.