Home > Articles > Programming > C/C++

C++ Reference Guide

Hosted by

Dynamic Linking: Advantages and Disadvantages

Last updated Jan 1, 2003.

The static linking model is simple to implement and use. This is its main advantage. However, it's pretty limiting. When you statically link a program, the resulting executable file must contain all the data and code that the program may ever need. Consequently, it can become ridiculously large.

In addition, changing or extending a program's behavior entails recompilation and relinking. Customers must therefore close the application before they install a new version of the executable whenever you supply an update. This may not sound like a serious problem until you think of your favorite Web browser, word processor, or operating system. Would you agree to reinstall any of these from scratch whenever a new version, bug fix, or update arrives?

Dynamic linking offers several advantages over static linking: code sharing, automatic updates, and security.

Code Sharing

With dynamic linking, programs can share identical code instead of owning individual copies of the same library. Think of the standard C or C++ libraries. They are both huge and ubiquitous. Every C or C++ program uses at least a portion of these libraries for I/O, date and time manipulation, memory allocation, string processing, and so on. If distinct copies of these libraries were statically linked into every executable file, even tiny programs would occupy dozens of megabytes.

Worse yet, whenever a new version of the said libraries is released, every executable file would have to be replaced with a newly-linked executable in order to reflect the change. Fortunately, these libraries are usually implemented as shared dynamic libraries that are loaded into the core program at runtime.

Automatic Updates

Whenever a new version of a dynamically-linked library is installed, it automatically supercedes the previous version. When you run a program, it automatically picks the most up-to-date version without forcing the user to re-link.


If you're concerned about protecting your intellectual property, splitting an application into several linkage units makes it harder for crackers to disassemble and decompile an executable file (at least in theory).

Dynamic Linking Disadvantages

Considering dynamic linking's prominent advantages, you could assume that it's superior to static linking by all means. This is not the case, though. Paradoxically, every advantage of dynamic linking can become a disadvantage under certain conditions. Let's look at these disadvantages more closely.

DLL Hell

While it is usually a good idea to share a single instance of a library rather than reduplicate it into every individual program, this sharing can become a serious problem. Think of two different Web browsers that reside on the same machine. Both browsers use the same shared libraries to access the system's modem, graphics card, and I/O routines. Now, suppose that you recently had to install an update of one of these shared libraries because of a security loophole found in the original version. Alas, the new version causes one of the browsers to crash. You can either wait for a new patch or revert to the previous version of the shared library.

None of these workarounds is ideal. Had the library been statically linked into each browser application, this mess would have been avoided. Unfortunately, such conflicts are reconciled only when you explicitly enable multiple versions of the same shared library to coexist on the same machine. However, this workaround complicates system management and forces users to become experts. In the Windows world, this problem is called the "DLL hell" although it exists in the POSIX world too.


Dynamic linking enables you to share identical code, which is usually a good idea. However, sharing the same data is rarely desirable.

If, for example, two processes call localtime(), it must return a different local static tm struct for every process. Designers of dynamically linked libraries were aware of this necessity and devised various techniques to cope with it. However, programmers must explicitly state which components of a shared library are truly shared and which ones aren't. The result is a larger and slower shared library as well as cluttered-up source files.

Code Cracking

Windows programmers who wish to thwart crackers' attempt to decompile their code often split an application into multiple DLLs. Ironically, this makes a cracker's job much easier because DLLs (and shared libraries in general) must contain metacode, i.e., code that documents code. This metacode (reminiscent of debug information) tells the runtime linker where each function and object is stored in the file, what their non-decorated names are, and so on. A hacker that knows how this information is encoded can decompile the code with less effort than required for decompiling an optimized, statically linked executable.


Dynamic linking is certainly an essential feature in today's software world. The C++ standardization committee is well aware of this. However, there are significant differences with respect to how each platform implements dynamic linking. In many ways, the dynamic linking model of Windows is the mirror image of UNIX's shared libraries, and vice versa. Consequently, defining a standard model of dynamic linking is a difficult task. The following draft addresses some of these issues in an attempt to define a standardized model of dynamic linking in C++. Hopefully, future revisions of the C++ standard will define a universal model of dynamic linkage, thereby facilitating cross-platform development and simplify learning.