Binding: Static vs Dynamic

Question

In my application, I have 3 main parts:

• Exe: executable file
• Lib_A: the library contains a singleton class and a base class for some calculations to be used in the singleton class
• Lib_B: the library contains several classes derived from the database in Lib_A

The reason I have derived classes in Lib_B is because I would like to compile Lib_B at runtime from Exe. I need to generate derived classes during calculations without interrupting the whole system. This is too important for me. This means that at first I can say that Lib_B1 is dynamically loaded, I can also compile other versions of Lib_B like Lib_B2, Lib_B3, Lib_B4, etc. And load them dynamically. All Lib_Bx libraries will have entry point functions for exporting classes to them.

So, given the following facts:

• At run time, there will be a different number of files having the same Lib_A.
• The application should run on Windows and Linux. Thus, partial cross-platform is a problem.
• I am going to use some libraries, such as TBB, Boost, Qt, which can have their own libraries, such as tbb.dll, etc.

What are the pros and cons of static or dynamic binding of Lib_A to Exe and Lib_Bx? How to affect performance, system size, etc.? Are there any dangerous or difficult situations that I can perform, in addition, for each OS I need to use the same compiler for Exe, Lib_A and Lib_Bx.

The design of the whole system is a very difficult question for me, so any comments will be appreciated.

Many thanks.

Answer 1

From what I understand in the description of your project, you should dynamically link Lib_A: if you link Lib_A statically with each of your shared Lib_Bx libraries, you will duplicate Lib_A code and static variables x times.

Let's say if you have a class in Lib_A that has the form:

class BaseKlass { static int instance_count; ... }; 

instance_count will be duplicated in all your shared libraries, which makes it impossible to count its BaseKlass instances.

You might be bitten by more subtle problems with virtual tables or RTTI (dynamic_cast), etc.

You should take a look at this boost.python file , which describes the problems associated with what I mentioned.

Boost.python allows you to create python modules (dynamic libraries) that must be loaded into the same process. Each python module created using boost.python, if they need to interact together at the C ++ level, for example by calling class B in a module from class A in another module, must dynamically bind to boost.python lib to avoid problems.

Answer 2

The big advantage of static binding is that you do not need to send a bunch of DLLs. If you plan on sending a bare executable, I think this is not a problem.

Dynamic binding has a number of great advantages. You do not need to recompile the entire application every time you make changes, but only modified DLLs. You can distribute the updated dll separately from the rest of the application, if they are compatible with ABI.

It may be easier to use the same compiler on Windows and Linux, but you definitely don't need to use the same compiler.

As long as you stick with portable libraries, the biggest difference between Windows and Linux is usually the build system. Some developers support completely separate build systems, but there are many cross-platform build systems such as cmake.

Answer 3

Do you want to create a new runtime? C ++ should not work like that. C ++ classes are static and compile time must exist. Shared, dynamically loaded libraries are not designed to solve the problem.

The simplest solution would be to implement a language interpreter with dynamic types (e.g. Lua) and write dynamic objects at runtime.

If you really want to interact with compiled modules while working regardless of the platform, you are better off using the neutral and neutral platform interface, such as CORBA. Then, things compiled and run in your Linux box and Windows box can interact with each other and compile new members to join the gang.

Answer 4

Basically, this is all possible if all three DLLs - you can start the compiler from your application and then dynamically load the new DLL. This is really the same as any other plugin architecture (think Lib_Bx DLLs will be plugins).

I would ask if this is really a wise approach. Do you need full C ++ compiler flexibility for your solution? Have you analyzed various solutions to the problem? If you do numerical processing, is OpenCL best suited?