Modern C++ Lamentations

[Jonathan M Davis]

On Thursday, January 3, 2019 4:52:56 AM MST rjframe via Digitalmars-d wrote:
> On Tue, 01 Jan 2019 19:04:24 -0700, Jonathan M Davis wrote:
> > From working with dlls with C++. With dlls on Windows, your program
> > links
> > against a static library associated with the dynamic library, and if any
> > of the symbols are changed, the addresses change, and your program will
> > be unable to load the newer version of the library without being rebuilt
> > against the new version of the static library.
>
> That's not necessarily true; Windows supports "implicit linking" and
> "explicit linking"; for implicit linking you do need to statically link
> against an import library, but for explicit linking you don't even need to
> know the DLL's name until runtime.
>
> With explicit linking you load the library by calling LoadLibrary/
> LoadLibraryEx, then call GetProcAddress with the name of your desired
> function to get the function pointer. If you watch the filesystem for the
> DLL to change, you could live-update by reloading the DLL (which you
> typically wouldn't do outside debugging or maybe if offering plugin
> support).
>
> Most people just do implicit linking because it's less work. Any DLL can
> be loaded in both ways, though if there's a DllMain there may be problems
> if the library author doesn't support both methods; for implicit linking,
> DllMain is run before the program entry point, but for explicit linking
> its called by LoadLibrary in the context of the thread that calls it.

*nix has the same distinction. It's a fundamentally different situation from
linking your executable against the library. You're really dynamically
loading rather than dynamically linking (though unfortunately, the
terminology for the two is not particularly distinct, and they're often
referred to the same way even though they're completely different). Loading
libraries that way is what you do when you do stuff like plugins, because
those aren't known when you build your program. But it makes a lot less
sense as an alternative to linking your program against the library if you
don't actually need to load the library like that. The COFF vs OMF mess on
Windows makes it make slightly more sense on Windows (at least with D, where
dmd uses OMF by default, unlike most of the C/C++ world at this point),
because then it doesn't matter whether COFF or OMF was used (e.g. IIRC,
Derelict is designed to be loaded that way for that reason), but in general,
it's an unnecessarily complicated way to use a library. And if Windows'
eccentricities make it more desirable than it is on *nix systems, then
that's just yet another black mark against how Windows does dynamic linking
IMHO.

- Jonathan M Davis