Чистый базовый класс должен быть экспортирован из DLL?
У меня есть два DLLs a.dll и b.dll и в каждом, который у меня есть один класс Класс А и BClass.
Я хотел бы иметь и Класс А и BClass, наследовали и реализуют тот же интерфейс AbsBase, который является чистым абстрактным классом.
В каждом классе я настроил #defines для __ declspec (dllimport) и __ declspect (dllexport). Когда я пытаюсь скомпилировать, я получаю это:
предупреждение C4275: не dll-соединяют-интерфейсом с классом 'Класс А', используемый в качестве основы для dll-интерфейсного класса 'AbsBase'
который в основном хочет, чтобы я объявил AbsBase как __ declspec (dllexport)
Но если бы компилятор имел бы это его путем, я должен был бы объявить, что AbsBase был экспортирован и из a.dll и из b.dll.
То, почему делает интерфейс класса, должно быть экспортировано?
Есть ли какой-либо путь вокруг этого? я должен действительно экспортировать AbsBase от обоих DLLs? нет ли что-то по сути неправильно с этим? (Я должен был бы определить новый макрос XXX_EXPORT..)
3 ответа
Похоже, это предупреждение компилятора, а не ошибка, поэтому оно должно работать. Компилятор просто сообщает вам, что вы делаете что-то, что облегчает вам ошибку. Это должно быть совершенно приемлемо, если и библиотеки DLL, и основная программа согласны с определением базового класса.
У вас должна быть возможность использовать прагму для подавления предупреждения:
У меня есть совет:
class Base {
public:
virtual void f() = 0;
virtual void g() = 0;
virtual ~Base();
};
class A: public Base {
public:
virtual void f();
virtual void g();
};
class B: public Base {
public:
virtual void g(); // REVERSE ORDER
virtual void f();
};
Порядок f и g в таблице виртуальных методов указан в базовом классе, и эта информация очень нужна.
Это повод для беспокойства. Компилятор обнаружил, что код в базовом классе может работать. Это не будет чисто виртуальный метод, он знает, как их фильтровать. Может быть, конструктор или деструктор? Режим отказа заключается в том, что структура памяти объекта класса может не совпадать в клиентском коде с DLL. Беспорядок во время выполнения, который это вызывает, очень трудно диагностировать.
Все будет в порядке, если вы можете гарантировать, что и клиент, и DLL скомпилированы с одинаковыми настройками компиляции и связывания, с использованием тех же самых версий CRT и этих инструментов. Вы можете сделать гарантированный базовый класс абстрактным, используя нестандартное ключевое слово __interface вместо class.