'GetProcAdress vs Linker
After doing some research on linking DLLs I came across two different methods for loading DLLs.
The first method was using the linker. I added the paths to the DLL's header(s) and the libraries and added to the linker options to link them. Then all I had to do was include the DLL's header(s) and it worked.
The second method was using GetProcAdress which is declared in the windows.h header. The was done by creating a HINSTANCE and set it with LoadLibrary("mylib.dll") (or whatever the DLL's name is that I'm linking) and setting a function point to the adress of GetProcAdress(hInstance, "myFunction").
Both of these work but I wanted to know which is more commonly used and is a better programming practice. And for the matter, which method is faster.
Thanks!
Solution 1:[1]
Both methods are used quite widely, and both are fast enough to disregard their speed.
The first method, "through linker", loads and links DLL upon program start. If a DLL is missing, the program won't start, and you have no control over this behaviour: this is how OS loads an executables. I'd say it is used more often, because it's just simpler to use. You just add a library file and don't worry about anything else, everything just works.
The second method, with LoadLibrary, gives you control over when and how you load DLLs; it allows you to unload and reload DLLs while the program is running, and your program is able to handle missing DLL in the way you specify. But that requires more efforts (writing all these LoadLibrary and GetProcAddress calls).
Which is better programming practice depends on how (and why) you use the DLLs. The first way covers most of cases.
Solution 2:[2]
There are pros/cons for both the methods. The first one can be used to export/import C++ classes. It's hard to do the same using LoadLibrary/GetProcAddress().
Though the second method is realistically limited to export/import C functions, it's often used to keep the binary compatibility. When you upgrade your DLL adding new export functions, without re-compiling applications that depend on the DLL, you can allow the new DLL work well with the old applications. It is difficult to do this with the first method. If you add new class member function for the exported C++ class, it requires re-compiling the application. Without re-compilation, you will see unexpected behavior (e.g. application crash) that is often very difficult to debug.
Solution 3:[3]
I always linked DLLs by using linker (first way as you specified) but when I needed to create a client application that loads DLL at runtime and adapts it's behaviors accordingly, (hot reloading feature for example) I see no other choices than runtime linking (The second way as you specified).
The second way was more painful for me since I needed to allocate classes of DLL in client application, so I can call GetProcAddress on them.
Sources
This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.
Source: Stack Overflow
| Solution | Source |
|---|---|
| Solution 1 | nullptr |
| Solution 2 | Ryoji |
| Solution 3 | iozsaygi |