¿Cuál es la forma más sencilla de escribir bibliotecas portátiles cargables dinámicamente en C++?

Question

Estoy trabajando en un proyecto que tiene varias rutas de código similares que me gustaría separar del proyecto principal en complementos. El proyecto debe seguir siendo compatible con todas las plataformas, y todas las API dinámicas de carga de bibliotecas que he analizado son específicas de la plataforma.

¿Cuál es la forma más sencilla de crear un sistema dinámico de carga de bibliotecas que se puede compilar y ejecutar en múltiples sistemas operativos sin modificación adicional del código? Idealmente, me gustaría escribir un complemento y hacer que funcione en todos los sistemas operativos que admite el proyecto.

Gracias.

Answer 1

Deberá usar el código dependiente de la plataforma para el sistema de carga . Es diferente cargar una DLL en Windows que cargar un objeto compartido en Unix. Pero, con un par de #ifdef, podrá tener la misma base de código en el cargador.

Habiendo dicho eso, creo que puede hacer que su plataforma de complementos sea independiente. Por supuesto, tendrá que compilarlo para cada plataforma, pero el código será el 99% el mismo.

Answer 2

La biblioteca dinámica que carga un Windows y Unix/Linux funciona con 3 funciones. Un par de funciones para cargar/descargar las bibliotecas, y otra función para obtener la dirección de una función en la biblioteca. Puede escribir fácilmente un envoltorio alrededor de estas tres funciones para proporcionar soporte de sistemas operativos cruzados.

Answer 3

Eche un vistazo a la biblioteca boost.extension, no es realmente parte de boost, pero puede encontrarla en el sandbox. También está algo congelado, pero en general la biblioteca es estable y fácil de usar.

Answer 4

Idealmente, me gustaría escribir un complemento y hacer que funcione en todos los sistemas operativos que admite el proyecto.

Pocas cosas desde la parte superior de mi cabeza:

• evitar los objetos estáticos en las bibliotecas dinámicas. Proporcione métodos/funciones de inicialización adecuados para asignar los objetos. Los problemas que ocurren durante la carga de la biblioteca por el sistema operativo (esto es cuando se llaman los códecs para objetos estáticos) son muy difíciles de depurar, solo después de los problemas de subprocesos múltiples.

• Los encabezados de interfaz pueden no contener código. No hay métodos en línea, ningún preprocesador define. Esto es para evitar contaminar la aplicación con el código de una versión particular de la biblioteca, por lo que es imposible reemplazar la biblioteca en otro momento.

• Los encabezados de interfaz no pueden contener clases de implementación en sí, solo clases abstractas y factory functions. Similar al punto anterior: evitar la aplicación depende de la versión particular de las clases. Se necesitan fábricas como una forma para que la aplicación del usuario cree instancias de las clases de implementación concretas.

• Al introducir una nueva versión de una interfaz, para mantener las cosas de alguna manera compatibles con versiones anteriores, no modifique la clase abstracta existente: cree una nueva clase abstracta heredada y agregue nuevos métodos allí. Cambia de fábrica para devolver la nueva versión. (Recordar MS 'IInterface, IInterface2, IInterface3 y así sucesivamente.) En la implementación, use la versión más nueva de la clase abstracta. Eso por polimorfismo haría la implementación retrocompatible con las versiones de interfaz más antiguas.(Eso obviamente requiere mantenimiento periódico de la interfaz y limpiezas - para eliminar la antigua cruft.)