c++ - plugin - run c in netbeans
¿Qué es seguro para un sistema de plug-in de C++? (8)
Creo que estás seguro creando un sistema de complementos basado en:
- Empaquetado de la funcionalidad del complemento en la biblioteca (.dll, .so, etc.)
- Exigir que el complemento exponga las exportaciones clave de C-idioma.
- Exigir que el complemento implemente (y devuelva un puntero / referencia) una interfaz abstracta de C ++.
Probablemente el sistema de plugins C ++ más exitoso: el viejo Adobe Photoshop . Y si no es así, uno de los formatos virtuales de sintetizador como VSTi, etc.
Los sistemas de complemento en C ++ son difíciles porque el ABI no está definido correctamente, y cada compilador (o versión del mismo) sigue sus propias reglas. Sin embargo, COM en Windows muestra que es posible crear un sistema de complemento mínimo que permita a los programadores con diferentes compiladores crear complementos para una aplicación host utilizando una interfaz simple.
Seamos prácticos, y dejemos el estándar de C ++, que no es muy útil a este respecto, aparte de un minuto. Si quiero escribir una aplicación para Windows y Mac (y opcionalmente Linux) que admita plug-ins de C ++, y si quiero dar a los autores de plug-in una amplia selección de compiladores (digamos versiones de Visual C ++ de menos de 2 años) , GCC o el compilador C ++ de Intel), ¿con qué características de C ++ podría contar?
Por supuesto, supongo que los complementos se escribirán para una plataforma específica.
Fuera de mi cabeza, aquí hay algunas características de C ++ que puedo pensar, con lo que creo que es la respuesta:
- diseño de vtable, para usar objetos a través de clases abstractas? (sí)
- tipos incorporados, punteros? (sí)
- estructuras, uniones? (sí)
- excepciones? (no)
- funciones externas "C"? (sí)
- stdcall non-extern "C" funciones con tipos de parámetros incorporados? (sí)
- no stdcall non-extern "C" funciones con tipos de parámetros definidos por el usuario? (no)
Apreciaría cualquier experiencia que tengas en esa área que puedas compartir. Si conoce alguna aplicación moderadamente exitosa que tenga un sistema de complemento C ++, también es genial.
Carl
El Diario del Dr. Dobb tiene un artículo Construyendo su propio marco de complemento: Parte 1, que es muy buena lectura sobre el tema. Es el comienzo de una serie de artículos que cubre la arquitectura, el desarrollo y la implementación de un marco de plugin multiplataforma de C / C ++.
El libro Imperfect C ++ de Matthew Wilson tiene una buena información sobre esto.
El consejo parece ser el siguiente: siempre que use el mismo compilador (o equivelant), puede usar C ++; de lo contrario, es mejor utilizar C como interfaz sobre su código C ++.
Firefox se ejecuta en XPCOM ( http://www.mozilla.org/projects/xpcom/ ). Está inspirado en Microsoft COM pero es multiplataforma.
También puede considerar reemplazar la interfaz de plugin convencional por una interfaz de scripting. Hay algunos enlaces muy buenos para varios lenguajes de scripting en C / C ++ que ya han resuelto su problema. Puede que no sea una mala idea construir sobre ellos. Por ejemplo, eche un vistazo a Boost.Python .
Tengo mi propio motor de juego que tiene un sistema de complemento C ++.
Tengo un código en los archivos de encabezado para que se ponga en la unidad de compilación del complemento.
Las funciones más grandes que viven en el motor principal se llaman a través de una función C exportada (el complemento llama a MyObject_somefunction (MyObject * obj) que en el motor simplemente llama a obj-> somefunction ()). Si llamar a una función C es feo para su gusto, entonces con algunos trucos de encabezado, cuando el encabezado se incluye en el complemento, haga que la función miembro sea definida para llamar a la función C:
#if defined(IN_THE_PLUGIN)
void MyObject::somefunction() { MyObject_somefunction(this); }
#endif
Las funciones virtuales deben ser puras o el código reside en el archivo de encabezado. Si no estoy heredando de una clase y simplemente instalando una, el código de función virtual puede vivir en el motor, pero luego la clase debe exportar algunas funciones C para crear y destruir el objeto que se llama desde el complemento.
Básicamente, los trucos que he usado, con el objetivo de mantener la independencia total de la plataforma, solo suman las exportaciones de C y los trucos del archivo de encabezado.
Qt tiene un sistema muy agradable para complementos que he usado en el pasado. Utiliza el sistema de metaobjetos de Qt para superar muchos de los problemas que suelen encontrarse al intentar desarrollar complementos de C ++.
Un ejemplo es cómo funciona Q_DECLARE_INTERFACE
, para evitar que use un complemento incompatible. Otra es la clave de compilación , para asegurarse de cargar el plugin correcto para su arquitectura, sistema operativo y compilador. Si no usas el sistema de complementos de Qt, estas son cosas de las que tendrás que preocuparte e inventar soluciones por ti mismo. No es necesariamente ciencia de cohetes, y no estoy diciendo que fallarías, pero los chicos de Trolltech son bastante inteligentes y han pasado un tiempo pensando en ello, y prefiero usar lo que crearon que reinventar la rueda yo mismo. .
Otro ejemplo es que RTTI generalmente no funciona a través de los límites de la DLL, pero cuando se usa Qt, cosas como qobject_cast que se basan en el sistema de metaobjetos funcionan a través de los límites de la DLL.
ACE tiene una arquitectura de complemento de plataforma cruzada.
Revisa:
Sugeriría revisar el libro
La guía del programador ACE