Динамические библиотеки, платформы плагинов и приведение указателей на функции в переполнении стека

Указатели на функции — странные существа. Они не обязательно имеют тот же размер, что и указатели данных, и, следовательно, их нельзя безопасно привести к void* и назад. Но спецификации C ++ (и C) позволяют любой указатель на функцию, который будет безопасно приведен к другому указателю на функцию тип (хотя вам придется затем привести его обратно к более раннему типу, прежде чем вызывать его, если вы хотите определенного поведения). Это похоже на возможность безопасно привести любой указатель данных к void* и назад.

Указатели на методы становятся там, где он становится действительно волосатым: указатель на метод может быть больше обычного указателя на функцию, в зависимости от компилятора, 32-разрядного или 64-разрядного приложения и т. Д. Но еще интереснее то, что даже на один и тот же компилятор / платформа, не все указатели на методы имеют одинаковый размер: указатели на виртуальные функции могут быть больше, чем обычные указатели на методы; если задействовано множественное наследование (например, виртуальное наследование в ромбовидной структуре), указатели метода могут быть еще больше. Это зависит от компилятора и платформы. Это также причина того, что трудно создавать функциональные объекты (которые обертывают произвольные методы, а также свободные функции), особенно без выделения памяти в куче (это просто возможно использование шаблон колдовства).

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

Поскольку нет гарантии, что указатели на функции будут одинакового размера от одного компилятора к другому, регистрируя указатели функций, вы ограничиваете авторов плагинов компиляторами, которые реализуют указатели функций того же размера, что и ваш компилятор. Это не обязательно будет так плохо на практике, поскольку размеры указателей на функции имеют тенденцию быть стабильными в разных версиях компилятора (и даже могут быть одинаковыми для нескольких компиляторов).

Реальные проблемы начинают возникать, когда вы хотите вызвать функции, на которые указывают указатели функций; Вы не можете безопасно вызывать функцию вообще, если не знаете ее истинную подпись (вы будут получить плохие результаты, начиная от «не работает» до ошибок сегментации). Таким образом, авторы плагина будут ограничены только регистрацией void функции, которые не принимают параметров.

Хуже того: то, как на самом деле работает вызов функции на уровне ассемблера, зависит не только от размера сигнатуры и указателя на функцию. Существует также соглашение о вызовах, способ обработки исключений (стек должен быть правильно размотан при возникновении исключения) и фактическая интерпретация байтов указателя функции (если он больше, чем указатель данных, что делают дополнительные байты означать? В каком порядке?). На этом этапе автор плагина в значительной степени ограничен использованием того же компилятора (и версии!), Что и вы, и должен быть осторожен, чтобы соответствовать соглашению о вызовах и опциям обработки исключений (с компилятором MSVC ++, например, обработкой исключений). только явно включен с /EHsc ), а также используйте только обычные указатели на функции с точной сигнатурой, которую вы определили.

Все ограничения пока Можно считаться разумным, если немного ограничивающим. Но мы еще не закончили.

Если вы добавите std::string (или почти любой части STL), все становится еще хуже, потому что даже с одним и тем же компилятором (и версией), есть несколько различных флагов / макросов, которые управляют STL; Эти флаги могут влиять на размер и значение байтов, представляющих строковые объекты. По сути, это похоже на два разные структурировать объявления в отдельных файлах с одинаковыми именами и надеяться, что они будут взаимозаменяемыми; очевидно, это не работает. Пример флага _HAS_ITERATOR_DEBUGGING, Обратите внимание, что эти параметры могут даже меняться между режимами отладки и выпуска! Эти типы ошибок не всегда проявляются сразу / последовательно, и их очень трудно отследить.

Вы также должны быть очень осторожны с динамическим управлением памятью между модулями, так как new в одном проекте может быть определено иначе new в другом проекте (например, он может быть перегружен). При удалении у вас может быть указатель на интерфейс с виртуальным деструктором, то есть vtable необходимо правильно delete объект, и различные компиляторы все реализуют vtable по-другому. В общем, вы хотите, чтобы модуль, который выделяет объект, был тем, который освобождает его; более конкретно, вы хотите код это освобождает объект для компиляции в тех же условиях, что и код, который его выделил. Это одна из причин std::shared_ptr может принимать аргумент «delete» при его создании — потому что даже с тем же компилятором и флагами (единственный гарантированный безопасный способ поделиться shared_ptrмежду модулями), new а также delete не может быть одинаковым везде shared_ptr может быть уничтожен. С помощью средства удаления код, который создает общий указатель, также управляет его уничтожением. (Я просто добавил этот абзац для хорошей меры; кажется, вы не разделяете объекты через границы модуля.)

Все это является следствием того, что C ++ не имеет стандартного двоичного интерфейса (ABI); Это все для всех, где очень легко выстрелить себе в ногу (иногда даже не осознавая этого).

Так есть ли надежда? Еще бы! Вместо этого вы можете представить C API своим плагинам, и ваши плагины также предоставят C API. Это очень хорошо, потому что C API может взаимодействовать практически с любым языком. Вам не нужно беспокоиться об исключениях, за исключением того, что они не всплывают над функциями плагина (это забота авторов), и они стабильны независимо от компилятора / опций (при условии, что вы не пропустите контейнеры STL). и тому подобное). Там только одно стандартное соглашение о вызовах (cdecl), который является значением по умолчанию для объявленных функций extern "C", void*на практике они будут одинаковыми для всех компиляторов на одной и той же платформе (например, 8 байтов на x64).

Вы (и авторы плагинов) по-прежнему можете писать свой код на C ++, при условии, что вся внешняя связь между ними использует C API (т.е. притворяется модулем C для взаимодействия).

Указатели на функции C, вероятно, также совместимы между компиляторами на практике, хотя, если вы не хотите зависеть от этого, вы можете попросить плагин зарегистрировать функцию название (const char*) вместо адреса, и затем вы можете извлечь адрес самостоятельно, например, LoadLibrary с GetProcAddress для Windows (аналогично, в Linux и Mac OS X есть dlopen а также dlsym). Это работает, потому что имя-коверкая отключено для функций, объявленных с extern "C",

Обратите внимание, что нет прямого способа ограничить зарегистрированные функции одним типом прототипа (в противном случае, как я уже сказал, вы не можете вызывать их должным образом). Если вам нужно передать конкретный параметр функции плагина (или вернуть значение), вам нужно зарегистрировать и вызывать разные функции с разными прототипами отдельно (хотя вы можете свернуть все указатели функций до общего указателя на функцию). введите внутренне, и только отбрасывайте в последнюю минуту).

Наконец, хотя вы не можете напрямую поддерживать указатели на методы (которые даже не существуют в C API, но имеют переменный размер даже при использовании C ++ API и поэтому не могут быть легко сохранены), вы можете разрешить плагинам предоставлять «пользовательский data «непрозрачный указатель при регистрации их функции, который передается функции всякий раз, когда она вызывается; это дает авторам плагинов простой способ написать обертки функций вокруг методов и сохранить объект для применения метода в параметре пользовательских данных. Параметр user-data также может использоваться для всего, что хочет автор плагина, что значительно упрощает взаимодействие и расширение вашей системы плагинов. Другим примером использования является адаптация между различными прототипами функций с использованием оболочки и дополнительных аргументов, хранящихся в пользовательских данных.

Эти предложения приводят к тому, что код выглядит примерно так (для Windows — код очень похож на другие платформы):

// Shared header
extern "C" {
typedef void (*plugin_function)(void*);

bool registerFunction(int plugin_id, const char* function_name, void* user_data);
}

// Your plugin registration code
hModule = LoadLibrary(pluginDLLPath);

// Your plugin function registration code
auto pluginFunc = (plugin_function)GetProcAddress(hModule, function_name);
// Store pluginFunc and user_data in a map keyed to function_name

// Calling a plugin function
pluginFunc(user_data);

// Declaring a plugin function
extern "C" void aPluginFunction(void*);
class Foo { void doSomething() { } };

// Defining a plugin function
void aPluginFunction(void* user_data)
{
static_cast<Foo*>(user_data)->doSomething();
}

Извините за длину этого ответа; большинство из них можно суммировать с помощью «стандарта C ++ не распространяется на взаимодействие; вместо этого используйте C, поскольку он по крайней мере имеет де-факто стандарты «.

Примечание. Иногда проще всего спроектировать нормальный API C ++ (с указателями функций или интерфейсами или любым другим способом) в предположении, что плагины будут скомпилированы при точно таких же обстоятельствах; Это разумно, если вы ожидаете, что все плагины будут разработаны вами (т.е. библиотеки DLL являются частью ядра проекта). Это также может сработать, если ваш проект с открытым исходным кодом, и в этом случае каждый может самостоятельно выбрать связную среду, в которой компилируются проект и плагины, но тогда это затрудняет распространение плагинов, за исключением исходного кода.

Обновить: Как отмечено в комментариях ern0, можно абстрагировать детали взаимодействия модуля (через C API), чтобы и основной проект, и плагины работали с более простым C ++ API. Далее следует краткое описание такой реализации:

// iplugin.h -- shared between the project and all the plugins
class IPlugin {
public:
virtual void register() { }
virtual void initialize() = 0;

// Your application-specific functionality here:
virtual void onCheeseburgerEatenEvent() { }
};

// C API:
extern "C" {
// Returns the number of plugins in this module
int getPluginCount();

// Called to register the nth plugin of this module.
// A user-data pointer is expected in return (may be null).
void* registerPlugin(int pluginIndex);

// Called to initialize the nth plugin of this module
void initializePlugin(int pluginIndex, void* userData);

void onCheeseBurgerEatenEvent(int pluginIndex, void* userData);
}// pluginimplementation.h -- plugin authors inherit from this abstract base class
#include "iplugin.h"class PluginImplementation {
public:
PluginImplementation();
};// pluginimplementation.cpp -- implements C API of plugin too
#include <vector>

struct LocalPluginRegistry {
static std::vector<PluginImplementation*> plugins;
};

PluginImplementation::PluginImplementation() {
LocalPluginRegistry::plugins.push_back(this);
}

extern "C" {
int getPluginCount() {
return static_cast<int>(LocalPluginRegistry::plugins.size());
}

void* registerPlugin(int pluginIndex) {
auto plugin = LocalPluginRegistry::plugins[pluginIndex];
plugin->register();
return (void*)plugin;
}

void initializePlugin(int pluginIndex, void* userData) {
auto plugin = static_cast<PluginImplementation*>(userData);
plugin->initialize();
}

void onCheeseBurgerEatenEvent(int pluginIndex, void* userData) {
auto plugin = static_cast<PluginImplementation*>(userData);
plugin->onCheeseBurgerEatenEvent();
}
}// To declare a plugin in the DLL, just make a static instance:
class SomePlugin : public PluginImplementation {
virtual void initialize() {  }
};
SomePlugin plugin;    // Will be created when the DLL is first loaded by a process// plugin.h -- part of the main project source only
#include "iplugin.h"#include <string>
#include <vector>
#include <windows.h>

class PluginRegistry;

class Plugin : public IPlugin {
public:
Plugin(PluginRegistry* registry, int index, int moduleIndex)
: registry(registry), index(index), moduleIndex(moduleIndex)
{
}

virtual void register();
virtual void initialize();

virtual void onCheeseBurgerEatenEvent();

private:
PluginRegistry* registry;
int index;
int moduleIndex;
void* userData;
};

class PluginRegistry {
public:
registerPluginsInModule(std::string const& modulePath);
~PluginRegistry();

public:
std::vector<Plugin*> plugins;

private:
extern "C" {
typedef int (*getPluginCountFunc)();
typedef void* (*registerPluginFunc)(int);
typedef void (*initializePluginFunc)(int, void*);
typedef void (*onCheeseBurgerEatenEventFunc)(int, void*);
}

struct Module {
getPluginCountFunc getPluginCount;
registerPluginFunc registerPlugin;
initializePluginFunc initializePlugin;
onCheeseBurgerEatenEventFunc onCheeseBurgerEatenEvent;

HMODULE handle;
};

friend class Plugin;
std::vector<Module> registeredModules;
}// plugin.cpp
void Plugin::register() {
auto func = registry->registeredModules[moduleIndex].registerPlugin;
userData = func(index);
}

void Plugin::initialize() {
auto func = registry->registeredModules[moduleIndex].initializePlugin;
func(index, userData);
}

void Plugin::onCheeseBurgerEatenEvent() {
auto func = registry->registeredModules[moduleIndex].onCheeseBurgerEatenEvent;
func(index, userData);
}

PluginRegistry::registerPluginsInModule(std::string const& modulePath) {
// For Windows:
HMODULE handle = LoadLibrary(modulePath.c_str());

Module module;
module.handle = handle;
module.getPluginCount = (getPluginCountFunc)GetProcAddr(handle, "getPluginCount");
module.registerPlugin = (registerPluginFunc)GetProcAddr(handle, "registerPlugin");
module.initializePlugin = (initializePluginFunc)GetProcAddr(handle, "initializePlugin");
module.onCheeseBurgerEatenEvent = (onCheeseBurgerEatenEventFunc)GetProcAddr(handle, "onCheeseBurgerEatenEvent");

int moduleIndex = registeredModules.size();
registeredModules.push_back(module);

int pluginCount = module.getPluginCount();
for (int i = 0; i < pluginCount; ++i) {
auto plugin = new Plugin(this, i, moduleIndex);
plugins.push_back(plugin);
}
}

PluginRegistry::~PluginRegistry() {
for (auto it = plugins.begin(); it != plugins.end(); ++it) {
delete *it;
}

for (auto it = registeredModules.begin(); it != registeredModules.end(); ++it) {
FreeLibrary(it->handle);
}
}// When discovering plugins (e.g. by loading all DLLs in a "plugins" folder):
PluginRegistry registry;
registry.registerPluginsInModule("plugins/cheeseburgerwatcher.dll");
for (auto it = registry.plugins.begin(); it != registry.plugins.end(); ++it) {
(*it)->register();
}
for (auto it = registry.plugins.begin(); it != registry.plugins.end(); ++it) {
(*it)->initialize();
}

// And then, when a cheeseburger is actually eaten:
for (auto it = registry.plugins.begin(); it != registry.plugins.end(); ++it) {
auto plugin = *it;
plugin->onCheeseBurgerEatenEvent();
}

Это дает преимущество использования C API для совместимости, но также предлагает более высокий уровень абстракции для плагинов, написанных на C ++ (и для основного кода проекта, который является C ++). Обратите внимание, что он позволяет определять несколько плагинов в одной DLL. Вы также можете устранить некоторые дубликаты имен функций, используя макросы, но я решил не делать этого простого примера.

Кстати, все это предполагает, что плагины не имеют взаимозависимостей — если плагин A влияет (или требуется) на плагин B, вам необходимо разработать безопасный метод для внедрения / построения зависимостей по мере необходимости, поскольку нет способа гарантировать в каком порядке плагины будут загружены (или инициализированы). Двухэтапный процесс будет хорошо работать в этом случае: загрузить и зарегистрировать все плагины; при регистрации каждого плагина, пусть они регистрируют любые услуги, которые они предоставляют. Во время инициализации создайте требуемые сервисы по мере необходимости, просматривая зарегистрированную таблицу сервисов. Это гарантирует, что все сервисы, предлагаемые всеми плагинами, зарегистрированы до любой из них пытается использоваться независимо от того, в каком порядке плагины регистрируются или инициализируются.