Estoy planeando hacer una interfaz de complemento C++ ala How to create some class from dll(constructor in dll)?(с++) pero ha surgido la preocupación de que si la interfaz se utiliza para crear archivos DLL a través de MinGW o Borland y el cargador DLL se compila con MSVC++, puede haber problemas. Como la única función exportada se declara externamente "C", ¿no veo por qué no funcionaría?Interfaz de complemento C++ DLL
Ideas?
Si quiere ser compatible con los compiladores (y Release/Debug) y usar C++, necesita un poco más de esfuerzo.
Básicamente, puede pasar tipos de datos básicos y apunta a clases virtuales puras. Estas clases no deben contener ningún miembro de datos, su destructor no debe ser público y no deberían tener funciones sobrecargadas.
La memoria no debe asignarse en una dll y liberarse en otra. Esto significa que no hay excepciones y necesita algún tipo de mecanismo de conteo o devolución de referencia.
Todos los métodos dentro de la clase virtual pura (también conocida como "Interfaz") deben estar marcados con una convención de llamadas (prefiero stdcall).
Los moldes dinámicos tampoco son posibles, por lo que es posible que necesite alguna funcionalidad en todas sus interfaces para hacer el truco (como QueryInterface en COM).
Esto funciona porque la mayoría de los compiladores de win32 intentan ser compatibles con COM y resuelven los mismos problemas de una manera compatible con COM. Para obtener la primera interfaz, necesita una función C simple que se exporta desde la dll.
Si solo usa las funciones C y los tipos de datos C, todo funcionará también. Pero luego está limitado a C sin clases & de herencia.
Espero que ayude.
Nombre mangling no es un problema:
primera: si utiliza funciones de C con tipos de datos C, todo está definido, no hay nombre mangling (excepción: en VS con STDCALL, es necesario reasignar el nombre del nombre C "normal" a través de la directiva Linker)
2º: Los métodos dentro de las clases no se exportan y, por lo tanto, no se destruyen. Usted llama a los métodos a través de puntero a clases virtuales puras (también conocidas como "Interfaces"). Esto usa un desplazamiento y ningún nombre. Aún no puede usar el destructor, ya que la posición del destructor dentro de la vblbl no está fija, por lo que sé.
Si pasa estructuras a funciones/métodos, asegúrese de corregir la alineación. No está definido en diferentes compiladores.
Una idea podría estar utilizando la función C externa estándar para crear una ClassFactory. Tenga alguna convención acerca de un punto de entrada fijo (o más) que el dll debe exponer para ser un complemento válido.
Sí, la única función exportada sería un complemento externo "C" * GetPluginObject(). He hecho esto antes, pero luego tuve el control de los archivos DLL (es decir, no dejé MinGW/Borland etc. en la ecuación) – Robert
¿Y si GetPluginObject devuelve una clase de alguna clase derivada de alguna clase virtual * pure *, aren ¿Es compatible la VTable entre las diferentes implementaciones del compilador? Creo que MS COM aprovecha estas ideas ... –
que son, en cierta medida. Ver mi respuesta arriba. –
¿Qué pasa con el nombre de mangling? ¿Será lo mismo para el destructor en diferentes compiladores? – ssmir
Entonces, ¿eso significa que no puede usar un complemento creado con un compilador diferente porque el símbolo del vtable puede ser diferente e incluso los desplazamientos del método pueden ser diferentes? – ssmir
Pero, ¿no es la estructura vtable definida por C++ estándar? Entonces no debería ser un problema usar un compilador diferente (compatible). – Robert