Linking : Static vs Dynamic

Question

In my application I have 3 major parts:

• Exe : an executable file
• Lib_A : a library contains a singleton class and a base class for some calculations to be use in singleton class
• Lib_B : a library contains a number of classes derived from the base in Lib_A

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

So taking the following facts into account :

• At runtime there will be various number of files sharing the same Lib_A.
• The application must run in Windows and Linux. So partial cross-platformness is an issue.
• I am going to use some libraries like TBB, Boost, Qt which may have their own libraries like tbb.dll etc.

What are the pros and cons of statically or dynamically linking of Lib_A against both Exe and Lib_Bx's? How can perfomance, size of system etc. be affected? Are there any dangerous or difficult situations I may encouter besides for each OS I need to use the same compiler for Exe, Lib_A and Lib_Bx's.

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

Thanks very much.

Finned

Answer 1

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

Say, if you have a class in Lib_A, that have the form :

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

instance_count will be duplicated in all your shared libraries, thus make it impossible for BaseKlass to count its instances.

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

You should have a look at this boost.python document that describes problems related to what I mentionned.

Boost.python allows to create python modules (dynamic libraries) that are to be loaded in the same process. Each python module created with boost.python, if they are to communicate together at the c++ level such as deriving a class B in a module from a class A in another module, is supposed to link dynamically with boost.python lib to avoid problems.

Persis

Answer 2

The big advantage of static linking is that you don't have to ship a bunch of DLL's. Unless you are planing on shipping a naked executable, I think it is a non issue.

Dynamic linking has some big advantages. You don't have to recompile the entire application each time you make a change, only the modified DLLs. You can distribute updated dll's separately from the rest of the application, as long as they are ABI compatible.

It might be simpler to use the same compiler on Windows and Linux, but you definitely do not have to use the same compiler.

As long as you stick to portable libraries, the biggest difference between Windows and Linux is usually the build system. Some developers maintain completely separate build systems, but there are plenty of cross platform build system like cmake.

Voss

Well I want to use MSVC++ compiler in Windows and Intel C++ compiler in Linux. I think both generates better optimized code than GCC does. The application is just for use of mine. I am not willing to sell it. – Finned

@sad_man: And you plan to get redistribution rights for VC and ICC? Good luck with that. – Ecstatics

@ephermient: I do not distiribute my application for now. But if I sell it in the future, then obviously the client will provide his/her own copy of compiler. I know it does not sound good but this is a trick to obtain the speed of compiled binary code. For now I am ok with VC and ICC. At the worst case I can distribute the application with GCC right? :) – Finned

@sad_man, unless you are doing some heavy duty number crunching, you won't notice a difference between compilers. You should be aware, the Intel runtime intentionally uses sub-optimal routines on non Intel chips. – Voss

@sad_man, Good luck getting a client to provide you with a compiler provide them with a custom build for them. – Voss

@sad_man: Keep in mind that redistributing GCC requires complying with the requirements of the General Public License. – Ecstatics

@ephemient, I don't know many people who care about the licensing terms of their compiler. It has no bearing on the the license of the application you are compiling. The license of the standard library can be important, but the gnu libraries have permissive licenses. – Voss

Answer 3

You want to create new classes runtime? C++ is not meant to work like that. C++ classes are static and should all exist compile time. Shared, dynamically loadable libraries are not meant to solve the issue.

Simplest solution might be to embed an interpreter of a language that has dynamic types (like Lua for example) and write the run-time dynamic objects in it.

If you really want to interact with run-time compiled modules in platform independent way then you better use some language neutral and platform neutral interface like CORBA. Then the things compiled and ran on your Linux box and Windows box can all interact with each other and compile new members to join the gang.

Grandaunt

But then I may not benefit the speed and flexibility of C++. – Finned

The speed of any application comes primarily from high skill of developers. Code generated from user input run-time should not be expected to be efficient, but might be useful where efficiency is not needed like for prototyping. Therefore i suggested to use some script interpreter. – Caresse

Yes Code generated from user input run-time should not be expected to be efficient BUT the binary code compiled from the user input run-time should be much faster then the code from a script interpreter. – Finned

Yes, once it is compiled. Invoking compiler is not cost free neither. Like i said C++ assumes static types so you can not create new C++ classes run-time. Perhaps you should then try to use some language-neutral interface like CORBA to interact with such run-time generated modules. – Caresse

How fast were you wanting it to run? Lua is comparably fast to C++ I would say. If you're doing something overly CPU intensive and complex then Lua will probably slow down, but for most things including pathfinding algorithms, it is still quite fast. Python is another option as is AngelCode (which the Wolfire team is using extensively in their new game) – Clarify

Answer 4

In principle this is all possible if all three are DLLs - you can trigger the compiler from your app and then dynamically load the new DLL. This is really just like any other plugin architecture (consider the Lib_Bx DLLs to be plugins).

I would question whether this is a wise approach though. Do you need the full flexibility of a C++ compiler for your solution? Have you profiled different ways of solving the problem? If you are doing numerical processing would something like OpenCL be a better approach?

Sashenka