Что безопасно для системы плагинов C ++?

Question

Подключаемые системы в C ++ сложны, потому что ABI не определен должным образом, и каждый компилятор (или его версия) следует своим собственным правилам. Однако COM в Windows показывает, что можно создать минимальную систему плагинов, которая позволит программистам с разными компиляторами создавать плагины для хост-приложения с помощью простого интерфейса.

Давайте будем практичными и оставим на минуту стандарт C ++, который не очень полезен в этом отношении. Если я хочу написать приложение для Windows и Mac (и, возможно, Linux), которое поддерживает плагины C ++, и если я хочу предоставить авторам плагинов достаточно большой выбор компиляторов (скажем, версии Visual C ++ менее двух лет) , Компилятор GCC или Intel C ++), на какие функции C ++ можно рассчитывать?

Конечно, я предполагаю, что плагины будут написаны для конкретной платформы.

Вдобавок ко всему, вот некоторые особенности C ++, о которых я могу подумать, и, как мне кажется, ответ:

• vtable layout, чтобы использовать объекты через абстрактные классы? (Да)
• встроенные типы, указатели? (Да)
• структуры, союзы? (Да)
• исключение? (Нет)
• внешние функции "C"? (Да)
• stdcall не внешние функции "C" со встроенными типами параметров? (Да)
• non-stdcall non-extern "C" функции с пользовательскими типами параметров? (Нет)

Буду признателен за любой опыт в этой области, которым вы могли бы поделиться. Если вам известно какое-либо приложение с умеренным успехом, в котором есть система плагинов C ++, это тоже здорово.

Карл

Answer 1

В журнале Dr Dobb's Journal есть статья Создание собственной структуры плагинов: часть 1 , которая довольно хорошо читается по этому вопросу. Это начало серии статей, посвященных архитектуре, разработке и развертыванию кросс-платформенной платформы плагинов C / C ++.

Answer 2

Qt имеет очень хорошую систему для плагинов, которую я использовал в прошлом. Он использует мета-объектную систему Qt для преодоления многих проблем, которые обычно возникают при разработке плагинов C ++.

Один пример - как работает Q_DECLARE_INTERFACE, чтобы предотвратить использование несовместимого плагина. Другим является ключ сборки , чтобы убедиться, что вы загружаете правильный плагин для вашей архитектуры, ОС, компилятора. Если вы не используете систему плагинов в Qt, вам придется беспокоиться и придумывать решения самостоятельно. Это не обязательно ракетостроение, и я не говорю, что вы потерпите в этом неудачу, но ребята из Trolltech довольно умны и потратили некоторое время на размышления об этом, и я бы лучше использовал то, что они создали, чем изобретать колесо сам .

Другой пример: RTTI обычно не работает через границы DLL, но при использовании Qt такие вещи, как qobject_cast , которые зависят от мета-объектной системы, работают через границы DLL .

Answer 3

Вы можете также рассмотреть возможность замены обычного интерфейса плагина интерфейсом сценариев. Есть несколько очень хороших привязок для нескольких языков сценариев в C / C ++, которые уже решили вашу проблему. Это может быть не плохая идея, чтобы строить на них. Например, взгляните на Boost.Python .

Answer 4

Книга Несовершенный С ++ Мэтью Уилсона содержит хорошую информацию об этом.

Похоже, совет: пока вы используете один и тот же (или equivelant) компилятор, вы можете использовать C ++, в противном случае вам лучше использовать C в качестве интерфейса поверх вашего кода C ++.

Answer 5

Я думаю, что вы в безопасности, создавая систему плагинов на основе:

• Упаковка функциональности плагина в библиотеку (.dll, .so и т. Д.)
• Требование, чтобы плагин предоставлял ключевые экспорты языка C.
• Требование, чтобы плагин реализовывал (и возвращал указатель / ссылку на) абстрактный интерфейс C ++.

Вероятно, самая успешная система плагинов C ++: старый добрый Adobe Photoshop . А если нет, то один из виртуальных синтезаторных форматов, таких как VSTi и т. Д.

Answer 6

Firefox работает на XPCOM (http://www.mozilla.org/projects/xpcom/). Он вдохновлен Microsoft COM, но он мультиплатформенный.

Answer 7

ACE имеет кроссплатформенную архитектуру плагинов.

Выезд:

1. ACE DLL
2. ACE DLL Manager

Я бы предложил проверить книгу
Руководство программиста ACE

Answer 8

У меня есть собственный игровой движок с системой плагинов C ++.

У меня есть некоторый код в заголовочных файлах, поэтому он помещается в модуль компиляции плагина.

Большие функции, которые живут в основном движке, вызываются через экспортированную функцию C (плагин вызывает MyObject_somefunction (MyObject * obj), которая в движке просто вызывает obj-> somefunction ()). Если вызов функции C неприятен на ваш вкус, то с некоторыми хитростями заголовка, когда заголовок включен в плагин, используйте функцию-член #defined для вызова функции C:

#if defined(IN_THE_PLUGIN)
void MyObject::somefunction() { MyObject_somefunction(this); }
#endif

Виртуальные функции либо должны быть чистыми, либо код находится в заголовочном файле. Если я не наследую от класса, а просто создаю экземпляр, код виртуальной функции может жить в движке, но тогда класс должен экспортировать некоторые функции C для создания и уничтожения объекта, вызываемого из плагина.

По сути, уловки, которые я использовал, с целью сохранения полной независимости платформы, сводятся к экспорту на С и трюкам с заголовочными файлами.