C ++ dllimport: неразрешенные внешние элементы со статическими полями

У меня есть проект Visual Studio C ++, содержащий основную программу и модуль DLL. В DLL есть класс со следующим определением:

// .h
#ifdef _USRDLL
    #define DLLAPI __declspec(dllexport)
#else
    #define DLLAPI __declspec(dllimport)
#endif

class DLLAPI EClass
{
public:
    static int value;

    static int get_value();
};

// .cpp
int EClass::value = 1;

int EClass::get_value()
{
    return value;
}

Проект DLL скомпилирован успешно, оба символа (значение и get_value) наблюдаются Dependency Walker.

В основной программе я могу вызвать статическую функцию get_value

int v = EClass::get_value();  // Ok, v = 1

но когда я пытаюсь получить доступ к полю value напрямую

int v = EClass::value;  // Error

Я получаю ошибку

LNK2001 unresolved external symbol "public: static int EClass::value" (?value@EClass@@2HA)

Можно ли избежать использования аксессоров для статических полей?


person Andrey Nasonov    schedule 26.09.2015    source источник
comment
Похоже, вы не экспортируете статику, вы пытались добавить DLLAPI перед ее объявлением? (для вне класса)   -  person SHR    schedule 27.09.2015
comment
возможно, также нужно добавить в заголовок: extern DLLAPI int EClass::value;, чтобы ваше приложение могло импортировать его в dll.   -  person SHR    schedule 27.09.2015
comment
Да, я безуспешно пробовал. Статическое поле экспортируется правильно: у меня есть доступ к нему с помощью метода доступа, и я вижу это поле в DLL.   -  person Andrey Nasonov    schedule 27.09.2015
comment
возможный дубликат экспорта статических данных в DLL   -  person wimh    schedule 27.09.2015
comment
@AndreyNasonov Вы используете свою dll из другой dll? Если это так, ваше использование макроса _USRDLL вместо уникального макроса для каждой dll может вызвать проблему, в любом случае для одной dll и одного exe, использующего его, он работает для меня без каких-либо изменений в моей Visual Studio 10 Express.   -  person SHR    schedule 27.09.2015
comment
Спасибо за правильный путь. Проблема заключалась в _USRDLL макросе, определенном в конфигурациях проекта DLL и EXE. Понятия не имею, как это произошло. Теперь все работает нормально.   -  person Andrey Nasonov    schedule 27.09.2015


Ответы (1)


Макрос _USRDLL следует определять только в проекте DLL.

person Andrey Nasonov    schedule 26.09.2015