Как лучше реализовать API для модулей?

Question

[Avery007]

Ситуация такова: есть EXE и DLL, которую этот исполняемый файл должен загружать. В этом DLL должны использоваться классы из EXE.
Так вот как мне дать DLL эту возможность? Конечно, C++ может вызвать виртуальные методы у указателей, но как быть с конструкторами и деструкторами классов?

Answer 1

[Станислав Макаров]

> Конечно, C++ может вызвать виртуальные методы у указателей
именно, поэтому вам нужно, как вариант:
1) сделать абстрактные интерфейсы вроде IFooService, библиотека будет отдавать указатели на объекты, их реализующие
2) сделать функции-фабрики и функции-уничтожители:

IFooService* CreateFooService(...);
void DestroyFooService(IFooService* service);

Это все нужно в частности для того, чтобы управление памятью не выходило за пределы DLL - иными словами, где порождается, там и убивается. Для большинства библиотек это приемлемое ограничение, которое позволяет сохранять ABI и даже использовать разные рантаймы для DLL и для EXE, его использующего.
Если вы будете передавать какие-то параметры по указателю, также следуйте этому правилу - не делайте так, что код в EXE выделяет память, а код в DLL - освобождает, и наоборот.
Ну и вообще, это хорошая абстракция интерфейса (ваш IFooService) от реализации (ваш конкретный класс FooService с конкретным конструктором и деструктором. К-р и д-р сложного класса должны оставаться частью _реализации_).
Если в качестве параметров, передающихся по значению вы используете struct-ы, это вполне допустимо, но тогда уже надо компилировать DLL и EXE одним компилятором, как этого требует, например, Qt (игнорирование этого правила рано или поздно приведет к странным и трудноуловим ошибкам, связанным с тем, что разные версии компилятора генерируют разный код конструкторов и деструкторов, и вообще могут по разному разложить struct в памяти).

Comments

[Avery007]

А насколько сильно использование фабрик скажется на производительности?

[MiiNiPaa]

Avery007: Зависит от реализации.
В примитивном виде там вообще только return new ConcreteFooService(...);

[Станислав Макаров]

@Avery007
> А насколько сильно использование фабрик скажется на производительности?
это обычная функция, т.е. ее вызов должнен быть даже дешевле, чем виртуальный вызов функции в интерфейсе (конечно, если не считать расходы на загрузку DLL в начале работы и прочие дела). А так да, как сказал MiiNiPaa - что туда положите, то там и будет. Смысл в том, что даже если там обычный new, и больше ничего - все равно это важно, т.к. вызов оператора new подразумевает знание РАЗМЕРА объекта (сколько место под поля выделить), а размер объекта в памяти - это по сути часть реализации, т.к. может изменяться при изменении кода реализации. Это вообще отдельная проблема в C++, различные библиотеки применяют различные подходы для ее решения, например Qt использует PImpl, погуглите.
Если вы вызываете new внутри библиотеки, то вызывающему функцию-фабрику НЕ НУЖНО знать о размере объекта, что принципиально важно: вы можете добавить пару полей в ваш ConcreteFooService, и вызывающее приложение перекомпилировать не нужно. Если вы вызывающее приложение делало new, то потребовалась бы его перекомпиляция, т.к. каждый new это выделение КОНКРЕТНОГО фиксированного объема памяти.
Таким образом, в случае использования фабрик такой аспект реализации, как размер объекта, остается в ведении DLL и не "вытекает" наружу, создавая вредные зависимости.

Answer 2

[Ilya Bobkov]

Сделайте класс импорта с виртуальными функциями. И загружайте в него его реализацию через LoadLibrary.