What is a real purpose of dynamic linking in c++?

Question

I'm new to this and don't understand why I should use dynamic linking when there is static linking.

1. I know that dynamic linking reduces the size of the program file, but if it is a custom dynamic library, it will still have to be included in the installer. So, the final size of the app folder will not change.
2. If the external library is already installed on the machine, how to determine and specify its location in the project settings (vs, cmake, qmake). During dynamic loading you can find out the location through system calls or Windows Registry. But how to do it during dynamic linking?

Please help me, because of these two points I don't understand why dynamic linking is needed at all (I can understand the need for dynamic loading).

Answer 1

Dynamic linking not only reduces the file size of your final executable, but it also improves the memory footprint of your application. If you have two applications, both that are statically linked and both use a common, shared library, then two copies of that same shared library will reside in memory, which is a waste. In general you will always want dynamic linking to produce the smallest and most efficient code.

So when is it appropriate to use static linking? Well if you're unsure of the target machine's OS version, statically linking your application can ensure that your application runs regardless of their version. Also, secure applications, such as financial applications, are a good candidate because it isolates one process from another by providing each an independent environment and no code is shared between any applications. Further on, static linking offers faster execution because we copy the entire library content at compile time. Hence, we don’t have to run the query for unresolved symbols at runtime. Thus, we can execute a statically linked program faster than a dynamically linked one.

Answer 2

I'm new to this and don't understand why I should use dynamic linking when there is static linking.

Note well that that static libraries and (therefore) static linking are the more traditional approach. Shared libraries and dynamic linking were devised and became overwhelmingly popular for a few main reasons:

1. Reduced storage size for applications relative to linking libraries statically
2. Reduced memory footprint for applications relative to linking libraries statically
3. Ability to fix bugs and make improvements once for all applications

Additionally,

4. some shared-object systems provide for whole applications to be shared objects, which extends the memory footprint advantage to cases of multiple instances of the application running concurrently.

5. some shared-library systems also provide additional features specific to shared libraries (dynamic loading, weak symbols, etc).

---

The primary advantages of static libs revolve primarily around control:

• if an application doesn't want to be dependent on the host system to provide a particular shared library, or
• if an application wants to control the specific version of the library code for compatibility or security purposes

then linking library code statically can address those issues.

---

1. I know that dynamic linking reduces the size of the program file, but if it is a custom dynamic library, it will still have to be included in the installer. So, the final size of the app folder will not change.

Maybe. But what if your project provides more than one executable depending on the library? That's not so uncommon, and in that case, making the library a dynamically-linked one does save space on your persistent storage device.

And even if you have only one executable, making it use shared libraries and / or be a shared object itself reduces the amount of memory required to run multiple instances concurrently.

In any case, if you're focusing on a custom library that you provide yourself then you should evaluate whether to structure it as a dynamic or static one based on your reasons for building a library in the first place. For example, if that's purely a convenience for structuring the build of a single executable, then probably it should be a static library -- but you might still want the overall executable to be a dynamic object.

On the other hand, if multiple executables will link the library, and especially if you intend to expose it for use by third-party applications, then you should probably provide a shared library version of it. You might choose to provide a static library version as well.

2. If the external library is already installed on the machine, how to determine and specify its location in the project settings (vs, cmake, qmake). During dynamic loading you can find out the location through system calls or Windows Registry. But how to do it during dynamic linking?

If it's installed in one of the places that the linker searches by default, then you don't need to locate it manually. If not, then the link-time problem is no different for dynamically-linked libraries than for statically-linked ones. When you have that problem then details of how you might solve it depend on OS and build framework. If you're using CMake, for example, then the shared library distribution can make provision for that (and many do) by providing CMake macros for determining library and header locations, among other details.

In any case, build details are something that relatively few people have to sort out, very few times. The operational pros and cons discussed at the beginning of this answer are at a much larger scale.

---

Of course, all of the above supposes that you have a choice at all. Not all systems offer one.