Vinculación: estático vs dinámico

Question

En mi aplicación tengo 3 partes principales:

• Exe: un archivo ejecutable
• Lib_A: una biblioteca contiene una clase Singleton y una clase base para algunos cálculos a su uso en Singleton clase
• Lib_B: una biblioteca contiene una serie de clases derivadas de la base en Lib_A

la razón por la que tengo las clases derivadas en Lib_B es, me gustaría compilar el Lib_B en tiempo de ejecución desde Exe. Necesito generar clases derivadas durante los cálculos sin terminar todo el sistema. Esto es muy importante para mi Eso significa que inicialmente puedo decir que Lib_B1 se cargó dinámicamente, también puedo compilar otras versiones de Lib_B como Lib_B2, Lib_B3, Lib_B4, etc. y cargarlas dinámicamente también. Todas las bibliotecas Lib_Bx tendrán funciones de punto de entrada para exportar las clases en ellas.

por lo que tomar los siguientes hechos en cuenta:

• En tiempo de ejecución, habrá varias número de archivos que comparten el mismo Lib_A.
• La aplicación debe ejecutarse en Windows y Linux. Entonces la multiplataforma parcial es un problema.
• voy a utilizar algunas librerías como TBB, Boost, Qt que puede tener sus propias bibliotecas como tbb.dll etc.

¿Cuáles son los pros y los contras de la vinculación estática o dinámica de Lib_A tanto contra Exe y Lib_Bx's? ¿Cómo se puede ver afectado el rendimiento, el tamaño del sistema, etc.? ¿Hay alguna situación peligrosa o difícil que pueda encontrar además de que para cada sistema operativo necesito usar el mismo compilador para Exe, Lib_A y Lib_Bx?

El diseño de todo el sistema es un problema muy difícil para mí, por lo que cualquier comentario será apreciado.

Muchas gracias.

Answer 1

Por lo que entiendo de la descripción de su proyecto, debe vincular Lib_A dinámicamente: si vincula Lib_A estáticamente a cada una de sus bibliotecas compartidas Lib_Bx, duplicará x veces el código Lib_A y las variables estáticas.

Es decir, si usted tiene una clase en Lib_A, que tiene la forma:

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

instance_count se duplicará en todas sus bibliotecas compartidas, por lo tanto hacer que sea imposible para BaseKlass para contar sus instancias.

lo que pueda ser mordido por problemas más sutiles con tablas virtuales o RTTI (dynamic_cast), etc.

Usted debe echar un vistazo a este boost.python document que describe los problemas relacionados con lo que lo mencionan.

Boost.python permite crear módulos de python (bibliotecas dinámicas) que se cargarán en el mismo proceso. Se supone que cada módulo python creado con boost.python, para comunicarse juntos en el nivel C++, como derivar una clase B en un módulo de una clase A en otro módulo, se vincula dinámicamente con boost.python lib para evitar problemas.

Answer 2

La gran ventaja de los enlaces estáticos es que no tiene que enviar un montón de DLL. A menos que esté planeando enviar un ejecutable desnudo, creo que no es un problema.

La vinculación dinámica tiene algunas grandes ventajas. No tiene que volver a compilar toda la aplicación cada vez que realice un cambio, solo las DLL modificadas. Puede distribuir dll actualizados por separado del resto de la aplicación, siempre que sean compatibles con ABI.

Puede ser más simple utilizar el mismo compilador en Windows y Linux, pero definitivamente no tiene que usar el mismo compilador.

Siempre y cuando se adhiera a las bibliotecas portátiles, la mayor diferencia entre Windows y Linux suele ser el sistema de compilación. Algunos desarrolladores mantienen sistemas de compilación completamente separados, pero hay muchos sistemas de compilación de plataforma cruzada como cmake.

Answer 3

¿Desea crear nuevas clases de tiempo de ejecución? C++ no debe funcionar así. Las clases de C++ son estáticas y todas deberían existir en tiempo de compilación. Las bibliotecas compartidas, dinámicamente cargables no están pensadas para resolver el problema.

La solución más simple podría ser incrustar un intérprete de un lenguaje que tenga tipos dinámicos (como Lua, por ejemplo) y escribir los objetos dinámicos en tiempo de ejecución en él.

Si realmente desea interactuar con los módulos compilados en tiempo de ejecución de una manera independiente de la plataforma, entonces es mejor utilizar una interfaz neutra en cuanto a la plataforma y la plataforma neutral como CORBA. Luego, las cosas compiladas y ejecutadas en su cuadro Linux y cuadro de Windows pueden interactuar entre sí y compilar nuevos miembros para unirse a la pandilla.

Answer 4

En principio, todo esto es posible si las tres son DLL: puede desencadenar el compilador desde su aplicación y luego cargar dinámicamente la nueva DLL. Esto es realmente como cualquier otra arquitectura de complemento (considere que las DLL Lib_Bx son complementos).

Me gustaría cuestionar si este es un enfoque sabio. ¿Necesita la flexibilidad total de un compilador de C++ para su solución? ¿Ha perfilado diferentes formas de resolver el problema? Si está haciendo un procesamiento numérico, ¿algo como OpenCL sería un mejor enfoque?