Экспорт функций из DLL с помощью dllexport - PullRequest
Новая
       49

Экспорт функций из DLL с помощью dllexport

91 голосов
/ 11 февраля 2009

Мне нужен простой пример экспорта функции из библиотеки DLL C ++.

Я бы хотел видеть заголовок, файл cpp и файл def (если это абсолютно необходимо).

Я бы хотел, чтобы экспортируемое имя было без декорации . Я хотел бы использовать самое стандартное соглашение о вызовах (__stdcall?). Я хотел бы использовать __declspec (dllexport) и не использовать файл DEF.

Например: 

  //header
  extern "C"
  {
   __declspec(dllexport) int __stdcall foo(long bar);
  }

  //cpp
  int __stdcall foo(long bar)
  {
    return 0;
  }

Я пытаюсь избежать того, чтобы компоновщик добавил подчеркивание и / или цифры (количество байтов?) К имени.

Я в порядке, не поддерживая dllimport и dllexport, используя один и тот же заголовок. Мне не нужна информация об экспорте методов класса C ++, только глобальные функции в стиле c.

UPDATE

Не включая соглашение о вызовах (и использование extern "C") дает мне имена экспорта, как мне нравится, но что это значит? Какое соглашение о вызовах по умолчанию я получаю, чего ожидают pinvoke (.NET), Declare (vb6) и GetProcAddress? (Я полагаю, что для GetProcAddress это будет зависеть от указателя функции, созданной вызывающей стороной).

Я хочу, чтобы эта DLL использовалась без заголовочного файла, поэтому мне не нужно много причудливых #defines, чтобы заголовок мог использоваться вызывающей стороной.

Я согласен с ответом, что мне нужно использовать файл DEF.

Ответы [ 4 ]

119 голосов
/ 11 февраля 2009

Если вы хотите простой экспорт C, используйте проект C, а не C ++. DLL-библиотеки C ++ основаны на распределении имен для всех измов C ++ (пространства имен и т. Д.). Вы можете скомпилировать свой код как C, зайдя в настройки вашего проекта в C / C ++ -> Advanced, есть опция «Compile As», которая соответствует переключателям компилятора / TP и /TC.

Экспорт / Импорт библиотек DLL в VC ++

Что вы действительно хотите сделать, так это определить условный макрос в заголовке, который будет включен во все исходные файлы в вашем проекте DLL: 

#ifdef LIBRARY_EXPORTS
#    define LIBRARY_API __declspec(dllexport)
#else
#    define LIBRARY_API __declspec(dllimport)
#endif

Затем для функции, которую вы хотите экспортировать, вы используете LIBRARY_API: 

LIBRARY_API int GetCoolInteger();

В вашем проекте сборки библиотеки создайте определение LIBRARY_EXPORTS, в результате чего ваши функции будут экспортированы для вашей сборки DLL.

Поскольку LIBRARY_EXPORTS не будет определен в проекте, использующем DLL, когда этот проект включает файл заголовка вашей библиотеки, все функции будут импортированы вместо него.

Если ваша библиотека должна быть кроссплатформенной, вы можете определить LIBRARY_API как ничего, если не в Windows: 

#ifdef _WIN32
#    ifdef LIBRARY_EXPORTS
#        define LIBRARY_API __declspec(dllexport)
#    else
#        define LIBRARY_API __declspec(dllimport)
#    endif
#elif
#    define LIBRARY_API
#endif

При использовании dllexport / dllimport вам не нужно использовать файлы DEF, если вы используете файлы DEF, вам не нужно использовать dllexport / dllimport. Два метода решают одну и ту же задачу по-разному, я считаю, что dllexport / dllimport является рекомендуемым методом из двух.

Экспорт неупорядоченных функций из C ++ DLL для LoadLibrary / PInvoke

Если вам нужно использовать LoadLibrary и GetProcAddress, или, возможно, сделать PInvoke из .NET, вы можете использовать extern "C" inline со своим dllexport. И поскольку мы используем GetProcAddress вместо dllimport, нам не нужно выполнять танец ifdef сверху, просто простой dllexport:

Код: 

#define EXTERN_DLL_EXPORT extern "C" __declspec(dllexport)

EXTERN_DLL_EXPORT int getEngineVersion() {
  return 1;
}

EXTERN_DLL_EXPORT void registerPlugin(Kernel &K) {
  K.getGraphicsServer().addGraphicsDriver(
    auto_ptr<GraphicsServer::GraphicsDriver>(new OpenGLGraphicsDriver())
  );
}

А вот как выглядит экспорт с Dumpbin / exports: 

  Dump of file opengl_plugin.dll

  File Type: DLL

  Section contains the following exports for opengl_plugin.dll

    00000000 characteristics
    49866068 time date stamp Sun Feb 01 19:54:32 2009
        0.00 version
           1 ordinal base
           2 number of functions
           2 number of names

    ordinal hint RVA      name

          1    0 0001110E getEngineVersion = @ILT+265(_getEngineVersion)
          2    1 00011028 registerPlugin = @ILT+35(_registerPlugin)

Так что этот код работает нормально: 

m_hDLL = ::LoadLibrary(T"opengl_plugin.dll");

m_pfnGetEngineVersion = reinterpret_cast<fnGetEngineVersion *>(
  ::GetProcAddress(m_hDLL, "getEngineVersion")
);
m_pfnRegisterPlugin = reinterpret_cast<fnRegisterPlugin *>(
  ::GetProcAddress(m_hDLL, "registerPlugin")
);
21 голосов
/ 28 января 2017

Для C ++:

Я только что столкнулся с той же проблемой, и я думаю, что стоит упомянуть, что проблема возникает, когда вы одновременно используете __stdcall (или WINAPI) и extern "C":

Как вы знаете, extern "C" удаляет украшение так, чтобы вместо: 

__declspec(dllexport) int Test(void)                        --> dumpbin : ?Test@@YaHXZ

Вы получаете имя символа без украшений: 

extern "C" __declspec(dllexport) int Test(void)             --> dumpbin : Test

Однако _stdcall (= макрос WINAPI, который изменяет соглашение о вызовах) также декорирует имена, так что если мы используем оба, мы получаем: 

   extern "C" __declspec(dllexport) int WINAPI Test(void)   --> dumpbin : _Test@0

и преимущество extern "C" теряется, потому что символ украшен (_ _bytes)

Обратите внимание, что это only происходит для архитектуры x86, потому что Соглашение __stdcall игнорируется в x64 ( msdn : в архитектурах x64, по соглашению аргументы передаются в регистры, когда это возможно, и последующие аргументы передаются в стек .).

Это особенно сложно, если вы нацелены на платформы как x86, так и x64.

Два решения

  1. Использовать файл определения. Но это заставляет вас сохранять состояние файла def.

  2. самый простой способ: определить макрос (см. msdn ):

# определение комментария EXPORT (компоновщик, "/ EXPORT:" __FUNCTION__ "=" __FUNCDNAME __)

и затем включите следующую прагму в тело функции: 

#pragma EXPORT

Полный пример: 

 int WINAPI Test(void)
{
    #pragma EXPORT
    return 1;
}

Эта функция экспортирует недекорированную функцию для целей x86 и x64, сохраняя при этом соглашение __stdcall для x86. __declspec(dllexport) в данном случае не требуется .

3 голосов
/ 23 сентября 2013

У меня была точно такая же проблема, мое решение было использовать файл определения модуля (.def) вместо __declspec(dllexport) для определения экспорта (http://msdn.microsoft.com/en-us/library/d91k01sh.aspx).. Я понятия не имею, почему это работает, но это делает

0 голосов
/ 11 февраля 2009

Я думаю, _naked может получить то, что вы хотите, но это также мешает компилятору генерировать код управления стека для функции. extern "C" вызывает оформление имени в стиле C. Удалите это, и это должно избавиться от ваших _. Компоновщик не добавляет подчеркивания, компилятор добавляет. stdcall добавляет размер стека аргументов.

Подробнее см .: http://en.wikipedia.org/wiki/X86_calling_conventions http://www.codeproject.com/KB/cpp/calling_conventions_demystified.aspx

Большой вопрос: почему ты хочешь это сделать? Что не так с искаженными именами?

...