2

I am looking for a clean way to explicitly load library. Most often, I have a LIB and DLL pair so the LIB will handle all the "load stuff" and I can directly call the function in the dll. When doing this explicitly, I need to do sort of the following:

HMODULE libA = LoadLibrary("dllA.dll"); // NULL if load failed
HMODULE libB = LoadLibrary("dllB.dll"); // NULL if load failed

void (*functionA)(void) = libA ? GetProcAddress(libA,"functionA"):NULL;
void (*functionB)(void) = libB ? GetProcAddress(libB,"functionB"):NULL;

It will be messy if the LoadLibrary() and GetProcAddress() are found all over my code when I need to call function in DLL. I would like to know if there is a clean way such that I can write all the handling within 1-2 files and call the functions as if I am loading the library implicitly through LIB and DLL pair.

Ronald Ku
  • 319
  • 2
  • 14
  • 2
    you can once, at one place, call `LoadLibrary` and than several times `GetProcAddress` for get all function pointers and than use it. you also can implement delay load for this dll – RbMm Oct 26 '17 at 08:39
  • 2
    This is programming 101. Create a function or class that wraps up this functionality for you and shields you from the details. – David Heffernan Oct 26 '17 at 08:42
  • You may also have a look at [Boost.DLL](http://www.boost.org/doc/libs/release/doc/html/boost_dll.html) which provides some abstraction. Haven't used it myself yet, but the [examples](http://www.boost.org/doc/libs/release/doc/html/boost_dll/tutorial.html#boost_dll.tutorial.plugin_basics) look quite clean. – zett42 Oct 26 '17 at 09:49

2 Answers2

2

Indeed there is a way to get all the implicit linking convenience, while still being able to gracefully handle both library load as well as symbol lookup failures. Visual Studio offers Linker Support for Delay-Loaded DLLs, that give user code the ability to hook into the loader, and implement arbitrary recovery strategies for unavailable symbols (e.g. by returning a no-op stub). This makes it possible to consolidate all failure handling into a single place.

IInspectable
  • 46,945
  • 8
  • 85
  • 181
  • I am currently using delay load too. My target is to have a more platform independent option. I know that load library and GetProcAddress are platform dependent too so I need a separate module to handle all these "load stuff" so that the module can be modified easily in the future. – Ronald Ku Oct 26 '17 at 09:51
  • 2
    @RonaldKu: Module loading is inherently platform-dependent. You can, however, provide a platform independent interface, e.g. by returning `nullptr`'s for unavailable symbols. Or `std::optional`'s, and using [value_or](http://en.cppreference.com/w/cpp/utility/optional/value_or) with a no-op stub pointer. I'll see if I can contrive some sample code to illustrate the concept, as time permits. – IInspectable Oct 26 '17 at 10:04
0

Write a pure interface to the external functions you need. (Platform dependent)

Provide an implementation class (for you platform). For your Windows implementation load the DLL, get the procedure address initially.

Than when the interface function need to be called, the class routes the call into the loaded DLL.

Use an similar way for other platforms.

This is nothing else than using of delay-loaded DLLs. It is just a manual solution. But the approach of using an interface allows you a real platform dependent solution.

xMRi
  • 14,982
  • 3
  • 26
  • 59