Експорт функцій з DLL з dllexport

Я хотів би простий приклад експорту функції з DLL C ++ Windows.

Я хотів би побачити заголовок, .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.

ОНОВЛЕННЯ

Якщо я не включаю конвенцію про виклики (і використовую extern "C"), мені надаються назви експорту, як мені подобається, але що це означає? Яка б умова виклику за замовчуванням я отримував те, що підключення (.NET), декларування (vb6), і GetProcAddressщо очікував? (Я думаю, для GetProcAddressцього це залежало б від вказівника функції, який викликав абонент).

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

Я все в порядку, відповідь полягає в тому, що я повинен використовувати *.defфайл.

Якщо ви хочете простий експорт C, використовуйте проект C, а не C ++. DLL-адреси C ++ покладаються на керування іменами для всіх C ++ -ів (простори імен тощо). Ви можете скласти свій код як C, зайшовши в налаштування свого проекту в розділі C / C ++ -> Advanced, є опція "Compile As", яка відповідає перемикачам компілятора / TP та / TC.

Якщо ви все ще хочете використовувати C ++ для написання внутрішніх даних вашої lib, але експортувати деякі функції без розблокування для використання поза C ++, див. Другий розділ нижче.

Експорт / імпорт DLL Libs у 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 є рекомендованим методом з двох.

Експорт безперервних функцій з DLL C ++ для LoadLibrary / PInvoke

Якщо вам це потрібно для використання LoadLibrary та GetProcAddress, або, можливо, імпортування з іншої мови (наприклад, PInvoke з .NET, або FFI в Python / R тощо), ви можете використовувати extern "C"вбудований текст за допомогою свого dllexport, щоб повідомити компілятору C ++ не маніпулювати іменами. А оскільки ми використовуємо 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 / експортом:

  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")
);

Для 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"втрачається через те, що символ прикрашений (з _ @ байтами)

Зауважте, що це відбувається лише для архітектури x86, оскільки умова__stdcall ігнорується на x64 ( msdn : для x64 архітектур, за умовою, аргументи передаються в регістри, коли це можливо, а наступні аргументи передаються на стек .).

Це особливо складно, якщо ви орієнтуєтесь як на платформи x86, так і на x64.

Два рішення

1. Використовуйте файл визначення. Але це змушує вас підтримувати стан файлу def.

2. найпростіший спосіб: визначити макрос (див. msdn ):

#define EXPORT коментар (посилання, "/ EXPORT:" __FUNCTION__ "=" __FUNCDNAME__)

а потім включіть таку прагму в тіло функції:

#pragma EXPORT

Повний приклад:

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

Це дозволить експортувати функцію незадекларованої як для цілей x86, так і для x64, зберігаючи __stdcallумову для x86. У цьому випадку __declspec(dllexport) це не потрібно.

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

Я думаю, що _naked може отримати те, що ви хочете, але це також заважає компілятору генерувати код управління стеком для функції. Зовнішній вигляд "C" викликає прикрасу назви стилю C. Видаліть це і те, що повинно позбутися ваших _. Лінкер не додає підкреслення, як робить компілятор. stdcall викликає додавання розміру стека аргументу.

Докладніше див: http://en.wikipedia.org/wiki/X86_calling_conventions http://www.codeproject.com/KB/cpp/calling_conventions_demystified.aspx

Питання більш важливе - чому ти хочеш це робити? Що не так з надуманими іменами?