Exportación de DLL C++ Class, pregunta sobre el archivo.def

build windows-ce

Question

Quiero usar enlaces implícitos en mi proyecto, y nmake realmente quiere un archivo .def. El problema es que esta es una clase y no sé qué escribir en la sección de exportaciones. ¿Alguien podría señalarme en la dirección correcta?

El mensaje de error es el siguiente:

NMAKE: U1073: no sé cómo hacer ''DLLCLASS.def''

PD: estoy tratando de construir usando Windows CE Platform Builder.

Answer 1

La solución es la siguiente:

• como se exporta una clase, también debe agregar los métodos exportados en el archivo .def

• No descubrí cómo exportar un constructor, así que utilicé un método de fábrica (estático), que devolverá nuevas instancias de un objeto

• las otras funciones se exportarán agregando una declaración de exportación normal en el archivo .def

Espero que alguien se beneficie de esta información.

Answer 2

Si recuerdo correctamente, puede usar __declspec(dllexport) en la clase , y VC ++ creará automáticamente exportaciones para todos los símbolos relacionados con la clase (constructores / destructor, métodos, vtable, typeinfo, etc.).

Microsoft tiene más información sobre esto aquí .

Answer 3

Siempre puede encontrar el nombre decorado para la función miembro utilizando dumpbin / symbols myclass.obj

en mi caso

class A {
   public:
     A( int ){}
};

el dumpbin volcado mostraba el símbolo ??0A@@QAE@H@Z (public: __thiscall A::A(int))

Al colocar este símbolo en el archivo .def, el enlazador crea el símbolo A :: A (int) en los símbolos de exportación.

¡PERO! como dice @paercebal en su comentario: la entrada manual de nombres decorados (truncados) es una tarea rutinaria, propensa a errores y, por desgracia, no se garantiza que sea portátil en todas las versiones del compilador.

Answer 4

Encontré la mejor ruta para ser una fábrica abstracta.

Comience por definir una clase base puramente virtual. Esta es una clase sin implementación, una clase de interfaz puramente virtual.

Puede exportar esta clase base virtual "interfaz abstracta", pero no hay una razón real para hacerlo. Cuando la persona que llama lo use, lo usará a través de un puntero (PImpl o Puntero a la Implementación) para que todo lo que la persona que llama sepa acerca de una simple dirección de memoria. Un archivo Def, mientras que un poco más de trabajo para mantenerse al día, proporciona beneficios más allá de lo que __declspec (dllexport) puede lograr. ¿Qué beneficios, preguntas? Llegaremos a eso, solo espera.

Haz que tu clase real herede públicamente de la base virtual. Ahora crea un método de fábrica para construir tu objeto y un destructor invocable de " liberación " para realizar la limpieza. Nombre estos métodos algo así como " ConstructMyClass " y " ReleaseMyClass ". Por favor, reemplace " MyClass " :-)

Esos métodos de fábrica / versión solo deberían tomar tipos POD si necesitan algún parámetro (plain-old-data: integer, char, etc.). El tipo de devolución debe ser su clase base de interfaz abstracta virtual, o más bien, un puntero a ella.

IMyClass * CreateAnObjectOfTypeIMyClass ();

Tal vez ahora es obvio por qué necesitamos la clase base virtual? Dado que la clase de interfaz virtual no tiene implementación, básicamente se trata de todos los tipos de POD (clasificación), por lo que la mayoría de las personas que llaman, como Visual Basic, C o compiladores de C ++ muy diferentes, pueden entender el "tipo de datos" de la clase.

Si es lo suficientemente elegante, puede evitar la necesidad de un método de " liberación manual " (lo siento, tuve que hacerlo). ¿Cómo? Administre sus propios recursos en la clase a través de smart-pointers y un tipo de arquitectura pImpl para que cuando el objeto muera, lo haga por sí mismo. Hacerlo significa que su clase es, en las palabras inmortales de nuestro santo y salvador Scott Meyers, " fácil de usar correctamente y difícil de usar de forma incorrecta " al dejar que la persona que llama ignore la necesidad de limpiar. Que aquellos entre nosotros que nunca han olvidado llamar " .close " arrojen la primera piedra.

¿Tal vez esta arquitectura te suena familiar? Debería, es básicamente una versión de micromáquina de COM. Bueno, una especie de, al menos, el concepto de interfaz, construcción y lanzamiento de fábrica.

Al final, ha exportado la interfaz para su clase, ha creado (y exportado) métodos Crear y Destruir , y ahora las personas que llaman pueden invocar su función de fábrica PleaseConstructMyClass para que su DLL devuelva un objeto totalmente construido, completamente implementado y completamente horneado bajo el disfraz de su interfaz. Pueden llamar a todos los métodos públicos de su clase (al menos los que están en su interfaz virtual abstracta) y hacer todas las cosas divertidas.

Cuando terminan con el objeto que devolvió la función de fábrica, pueden llamar a la función " ReleaseMyClass " para solicitarle a su DLL que limpie los recursos del objeto, o puede ayudarlos haciendo que su clase se limpie, haciendo el método " ReleaseMyClass " es redundante e inútil.

Si alguien está interesado en las ganancias y compensaciones específicas para usar el archivo Def y la interfaz (además de mi versión ciega), por favor dirígete y podremos profundizar más.

¿No te encanta esto?