visual studio sobrecarga relacionales poo operadores operador funciones crear c++ c dll

studio - sobrecarga de operadores relacionales en c++



Funciones sobrecargadas en C++ DLL def file (6)

En el código mismo, marque las funciones que desea exportar usando __declspec (dllexport). Por ejemplo:

#define DllExport __declspec(dllexport) int DllExport Foo( int a ) { // implementation } int DllExport Foo( int a, int b ) { // implementation }

Si hace esto, no necesita enumerar las funciones en el archivo .def.

Alternativamente, puede usar un valor de parámetro predeterminado, como:

int Foo( int a, int b = -1 )

Esto supone que existe un valor para b que puede usar para indicar que no se usa. Si -1 es un valor legal para b, o si no hay o no debe haber un valor predeterminado, esto no funcionará.

Editar (Adam Haile): Corregí para usar __declspec porque __dllspec no era correcto, así que podía marcarlo como la respuesta oficial ... estaba lo suficientemente cerca.

Editar (Graeme): Vaya, gracias por corregir mi error tipográfico.

Estoy escribiendo una DLL C / C ++ y quiero exportar ciertas funciones que he hecho antes de usar un archivo .def como este

LIBRARY "MyLib" EXPORTS Foo Bar

con el código definido así, por ejemplo:

int Foo(int a); void Bar(int foo);

Sin embargo, ¿qué ocurre si quiero declarar un método sobrecargado de Foo () como:

int Foo(int a, int b);

Como el archivo def solo tiene el nombre de la función y no el prototipo completo, no puedo ver cómo manejaría las funciones sobrecargadas. ¿Utiliza la única entrada y luego especifica qué versión sobrecargada desea al pasar el puntero de la función de prototipo adecuado a LoadLibrary ()?

Editar: para que quede claro, esto está en Windows usando Visual Studio 2005

Editar: Marcó el método non-def (__declspec) como la respuesta ... Sé que esto realmente no resuelve el problema usando archivos def como yo quería, pero parece que no hay una solución (oficial) que use archivos def. Sin embargo, dejaremos la pregunta abierta, en caso de que alguien sepa algo, no tenemos funciones sobrecargadas ni archivos def.


La definición de Systax for EXPORTS es:

entryname[=internalname] [@ordinal [NONAME]] [PRIVATE] [DATA]

entryname es la función o nombre de variable que desea exportar. Esto es requerido. Si el nombre que exporta es diferente del nombre en la DLL, especifique el nombre de la exportación en la DLL con el nombre interno.

Por ejemplo, si su DLL exporta una función, func1 () y desea que se use como func2 (), debe especificar:

EXPORTS func2=func1

Simplemente vea los nombres destrozados (usando Dependency walker) y especifique el nombre de su propia función.

Fuente: http://msdn.microsoft.com/en-us/library/hyx1zcd3(v=vs.71).aspx

Editar: Esto funciona para archivos DLL dinámicos, donde necesitamos usar GetProcAddress () para obtener funciones de manera explícita en Dll.


La sobrecarga de funciones es una función de C ++ que se basa en la creación de nombres (los nombres de las funciones crípticas en los mensajes de error del vinculador).

Al escribir los nombres destrozados en el archivo def, puedo hacer que mi proyecto de prueba se vincule y se ejecute:

LIBRARY "TestDLL" EXPORTS ?Foo@@YAXH@Z ?Foo@@YAXHH@Z

parece funcionar para

void Foo( int x ); void Foo( int x, int y );

Copie los nombres de las funciones C ++ del mensaje de error y escríbalos en su archivo def. Sin embargo, la verdadera pregunta es: ¿Por qué quieres usar un archivo def y no ir con __declspec (dllexport)?

Los nombres mutilados no son portátiles, probé con VC ++ 2008.


No existe una forma de agnóstico de idioma o versión para exportar una función sobrecargada ya que la convención de cambio puede cambiar con cada versión del compilador.

Esta es una razón por la cual la mayoría de las funciones de WinXX tienen nombres divertidos como * Ex o * 2.


No hay una forma oficial de hacer lo que quieras, porque la interfaz dll es una C api.

El compilador usa nombres mutilados como una solución alternativa, por lo que debe usar el cambio de nombre cuando no desee cambiar demasiado en su código.


Tuve un problema similar, así que quería publicarlo también.

  1. Usualmente usando

    extern "C" __declspec(dllexport) void Foo();

    exportar un nombre de función está bien. Por lo general, exportará el nombre sin marcar sin la necesidad de un archivo .def. Sin embargo, hay algunas excepciones como __stdcall funciones y nombres de funciones sobrecargadas.

  2. Si declara una función para usar la convención __stdcall (como se hace para muchas funciones API), entonces

    extern "C" __declspec(dllexport) void __stdcall Foo();

    exportará un nombre destrozado como _Foo @ 4. En este caso, es posible que deba asignar explícitamente el nombre exportado a un nombre interno destrozado.

A. Cómo exportar un nombre no protegido. En un archivo .def agregar

---- EXPORTS ; Explicit exports can go here Foo -----

Esto intentará encontrar una "mejor coincidencia" para una función interna Foo y exportarla. En el caso anterior, donde solo hay un foo, esto creará el mapeo

Foo = _Foo @ 4

como se puede ver a través de dumpbin / EXPORTACIONES

Si ha sobrecargado un nombre de función, es posible que deba indicar explícitamente qué función desea en el archivo .def especificando un nombre alterado utilizando la sintaxis entryname [= internalname]. p.ej

---- EXPORTS ; Explicit exports can go here Foo=_Foo@4 -----

B. Una alternativa a los archivos .def es que puedes exportar nombres "en su lugar" usando un #pragma.

#pragma comment(linker, "/export:Foo=_Foo@4")

C. Una tercera alternativa es declarar sin registro una sola versión de Foo como extern "C". Mira aquí para más detalles.