Форум программистов, компьютерный форум CyberForum.ru

Теория плагинов - C++

Восстановить пароль Регистрация
 
 
Рейтинг: Рейтинг темы: голосов - 185, средняя оценка - 4.83
niXman
Эксперт C++
 Аватар для niXman
3133 / 1445 / 49
Регистрация: 09.08.2009
Сообщений: 3,441
Записей в блоге: 2
30.04.2010, 17:02     Теория плагинов #1
Всем привет.
Для одной моей проги, нужно реализовать поддержку плагинов.
Плагины предполагаются простенькие, написанные на Си.

То, что плагин, это просто .so файл - понятно.
То, что прога может дергать из .so файла функции - тоже понятно.

1. Непонятно то, как сам плагин сможет дергать функции из программы?
2. Программа написана на С++, но плагины предполагаю писать на Си, во избежания бинарной несовместимости. В этом случае, какие сложности могут возникнуть?
3. Еще непонятно, каким образом "разделять" плагины, ведь их может быть несколько?
4. И еще непонятно, каким образом программе "сообщить" какие функции дергать из конкретного плагина?
5. И еще непонятно, каким образом плагин, сможет дергать функции из другого плагина?

Нужна теоретическая подкова

Благодарен всем откликнувшимся.
Similar
Эксперт
41792 / 34177 / 6122
Регистрация: 12.04.2006
Сообщений: 57,940
30.04.2010, 17:02     Теория плагинов
Посмотрите здесь:

C++ теория
теория C++
теория C++
Теория C++
Взаимодействие плагинов C++
теория C++
C++ Подключение плагинов к программе
После регистрации реклама в сообщениях будет скрыта и будут доступны все возможности форума.
Evg
Эксперт С++Автор FAQ
 Аватар для Evg
16935 / 5340 / 328
Регистрация: 30.03.2009
Сообщений: 14,349
Записей в блоге: 26
01.05.2010, 00:56     Теория плагинов #2
Цитата Сообщение от niXman Посмотреть сообщение
1. Непонятно то, как сам плагин сможет дергать функции из программы?
Элементарно по имени. Если программа гарантирует, к примеру, что в программе есть функция func1, то в плагине можно написать extern-описание и дёргать по имени. Если плагин на Си, а программа на Си++, то в программе функция должна быть описана как extern "C". Можно в плагин подсовывать указатели на функции.

Цитата Сообщение от niXman Посмотреть сообщение
2. Программа написана на С++, но плагины предполагаю писать на Си, во избежания бинарной несовместимости. В этом случае, какие сложности могут возникнуть?
Принципиальных - нет. Понятно, что общение между программой и плагином будет в терминах языках Си - никаких классов и прочей лабудени.

Цитата Сообщение от niXman Посмотреть сообщение
3. Еще непонятно, каким образом "разделять" плагины, ведь их может быть несколько?
plugin1.so, plugin2.so
Или я не понял вопроса

Цитата Сообщение от niXman Посмотреть сообщение
4. И еще непонятно, каким образом программе "сообщить" какие функции дергать из конкретного плагина?
Варианты бывают разные, но в любом случае плагин пишется не от балды, а согласно некоторому зафиксированному интерфейсу. Например, возможен такой вариант, что плагин обязан иметь функции func1, func2 с такими-то интерфейсами и переменные var1, var2 таких-то типов

Цитата Сообщение от niXman Посмотреть сообщение
5. И еще непонятно, каким образом плагин, сможет дергать функции из другого плагина?
Можно точно так же - по имени. Но это слишком замудрёно (например, тогда один плагин не сможет работать без другого). Более правильный вариант - это когда главная программа является посредником, добывает из первого плагина указатель на функцию и отдаёт его во второй плагин.
niXman
Эксперт C++
 Аватар для niXman
3133 / 1445 / 49
Регистрация: 09.08.2009
Сообщений: 3,441
Записей в блоге: 2
01.05.2010, 03:01  [ТС]     Теория плагинов #3
Цитата Сообщение от Evg Посмотреть сообщение
Элементарно по имени.
так эти функции должны быть экспортируемые из программы? что-то не понимаю..

Цитата Сообщение от Evg Посмотреть сообщение
plugin1.so, plugin2.so
и вправду, все гениальное просто

Цитата Сообщение от Evg Посмотреть сообщение
Или я не понял вопроса
допустим, программа экспортирует некую функцию, которая для определенных плагинов, ведет себя по особенному.

Цитата Сообщение от Evg Посмотреть сообщение
Варианты бывают разные, но в любом случае плагин пишется не от балды, а согласно некоторому зафиксированному интерфейсу. Например, возможен такой вариант, что плагин обязан иметь функции func1, func2 с такими-то интерфейсами и переменные var1, var2 таких-то типов
тут понятно.

Цитата Сообщение от Evg Посмотреть сообщение
Можно точно так же - по имени. Но это слишком замудрёно (например, тогда один плагин не сможет работать без другого). Более правильный вариант - это когда главная программа является посредником, добывает из первого плагина указатель на функцию и отдаёт его во второй плагин.
теория понятна. в реализации не очень.. буду спрашивать по ходу..
Evg
Эксперт С++Автор FAQ
 Аватар для Evg
16935 / 5340 / 328
Регистрация: 30.03.2009
Сообщений: 14,349
Записей в блоге: 26
01.05.2010, 11:06     Теория плагинов #4
Цитата Сообщение от niXman Посмотреть сообщение
так эти функции должны быть экспортируемые из программы? что-то не понимаю..
Понятия типа "экспортирует", "импортирует" скорее характерны для языков типа паскаля или оберона, но условно можно сказать, что так

Цитата Сообщение от niXman Посмотреть сообщение
допустим, программа экспортирует некую функцию, которая для определенных плагинов, ведет себя по особенному.
Функция всегда ведёт себя одинаково, наличие плагина не должно влиять на работу

Ты лучше поясни конкретно, что хочешь
Vourhey
Почетный модератор
6470 / 2245 / 123
Регистрация: 29.07.2006
Сообщений: 12,635
01.05.2010, 12:20     Теория плагинов #5
niXman, если у тебя какая-то функция в определенных плагинах ведет себя совсем "по-особенному", то лучше будет разделить твои плагины по типу. К примеру, чтобы любой твой плагин экспортировал функцию, допустим, getType(), которая вернет тип плагина. Это может быть число или строчка, как угодно. Твоя основная программа будет всегда будет вызывать эту функцию после загрузки .so и определять с каким типом плагина она имеет дело и соответстенно знать, что в общих чертах будут делать функции этого плагина.
Или я не понял вопрос
niXman
Эксперт C++
 Аватар для niXman
3133 / 1445 / 49
Регистрация: 09.08.2009
Сообщений: 3,441
Записей в блоге: 2
10.03.2011, 16:41  [ТС]     Теория плагинов #6
а как экспортировать классы из плагина?
к примеру, мне нужно, чтоб некоторый плагин определял реализацию некоторого класса. при этом, программа, знает экспортируемый тип только по интерфейсу. тогда, полагаю, в плагине должна быть функция типа create()

пример:
C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
// интерфейс.
class i_type {
   i_type(int);
   ~i_type();
 
   virtual int get() const = 0;
   virtual int add(int) = 0;
};
 
// реализация для типа в плагине
class type: public i_type {
   type(int v):i_type(v) {}
   virtual ~type() {}
 
   virtual int get() const { return 3; }
   virtual int add(int v) { return 3+v; }
};
 
// функция плагина создающая объект
i_type* create(int v) {
   return new type(v);
}
какие в этом случае меня ожидают проблемы, возможно в будущем?
как все же экспортировать классы из плагина?

спасибо.
Evg
Эксперт С++Автор FAQ
 Аватар для Evg
16935 / 5340 / 328
Регистрация: 30.03.2009
Сообщений: 14,349
Записей в блоге: 26
10.03.2011, 17:24     Теория плагинов #7
Вообще говоря, классы нельзя "экспортировать". В Си++ компилятор должен явно видеть описание класса. Можно конечно мухлевать с виртуальными классами, но так или иначе у тебя будут экспортироваться действия или данные, но не типы
niXman
Эксперт C++
 Аватар для niXman
3133 / 1445 / 49
Регистрация: 09.08.2009
Сообщений: 3,441
Записей в блоге: 2
10.03.2011, 17:47  [ТС]     Теория плагинов #8
т.е. приведенный мною код, не жизнеспособен?
Evg
Эксперт С++Автор FAQ
 Аватар для Evg
16935 / 5340 / 328
Регистрация: 30.03.2009
Сообщений: 14,349
Записей в блоге: 26
10.03.2011, 18:00     Теория плагинов #9
Жизнеспособность кода зависит от того, что ты вкладываешь в это понятие. Ты же по сути не экспортируешь новые типы, а экспортируешь лишь указатель на объект, приведённый к базовому типу. Основная программа может через этот указатель вызывать методы класса i_type, но фактически это означает лишь работу с кодами и с данными. Но не с типом.

Это вовсе не есть экспортирование производного типа, а всего лишь обычное виртуальное наследование.
niXman
Эксперт C++
 Аватар для niXman
3133 / 1445 / 49
Регистрация: 09.08.2009
Сообщений: 3,441
Записей в блоге: 2
10.03.2011, 18:13  [ТС]     Теория плагинов #10
Цитата Сообщение от Evg Посмотреть сообщение
зависит от того, что ты вкладываешь в это понятие.
эм... что он должен работать

Цитата Сообщение от Evg Посмотреть сообщение
Ты же по сути не экспортируешь новые типы, а экспортируешь лишь указатель на объект, приведённый к базовому типу.
этот способ я надумал после того, как ты сказал что классы нельзя экспортировать.

Цитата Сообщение от Evg Посмотреть сообщение
Основная программа может через этот указатель вызывать методы класса i_type, но фактически это означает лишь работу с кодами и с данными. Но не с типом.
поясни, что имеется ввиду?

Цитата Сообщение от Evg Посмотреть сообщение
Это вовсе не есть экспортирование производного типа, а всего лишь обычное виртуальное наследование.
ок.
а как реализовать экспортирование? или это все же никоим образом невозможно?
Evg
Эксперт С++Автор FAQ
 Аватар для Evg
16935 / 5340 / 328
Регистрация: 30.03.2009
Сообщений: 14,349
Записей в блоге: 26
10.03.2011, 18:30     Теория плагинов #11
Цитата Сообщение от niXman Посмотреть сообщение
поясни, что имеется ввиду?
Основная программа видит лишь указатель на type_i, и она не может сделать чего-то большего, чем описано в этом классе (о котором программа и так знает). Т.е. для программы нового типа не появилось.

Цитата Сообщение от niXman Посмотреть сообщение
а как реализовать экспортирование? или это все же никоим образом невозможно?
Заводишь какую-нибудь структуру, в котором как-то писываешь тип (да хоть в текстововм виде). Описываешь какие-то ацкие функции для работы с таким описанием типа. Фактически пишешь интерпретатор. Собственно - по другому тип и никак нельзя экспортировать. Те языки, которые имеют такую возможность, так или иначе реализованы через что-то наподобие интерпретатора, который включен в динамическую поддержку языка. (и таким образом всем этим занимаются разработчики комплятора, а не пользователи)
g_u_e_s_t
1258 / 649 / 30
Регистрация: 06.02.2011
Сообщений: 1,724
10.03.2011, 18:33     Теория плагинов #12
Не очень вникал в трид, но предложу такое:
C++
1
2
3
4
5
6
7
8
9
10
11
#define EXPORT __attribute__((visibility("default")))
 
class EXPORT myclass{
public:
myclass(...);
 
virtual int mymethod();
int p;
};
 
typedef myclass* myclass_t(...);
niXman
Эксперт C++
 Аватар для niXman
3133 / 1445 / 49
Регистрация: 09.08.2009
Сообщений: 3,441
Записей в блоге: 2
10.03.2011, 18:46  [ТС]     Теория плагинов #13
Добавлено через 1 минуту
Evg, и последний вопрос: можешь пояснить более популярно чем в куче манов, что конкретно выполняет флаг -fPIC при либковке .so файла?

обсуждение продолжено здесь: Вопросы по динамическим библиотекам
niXman
Эксперт C++
 Аватар для niXman
3133 / 1445 / 49
Регистрация: 09.08.2009
Сообщений: 3,441
Записей в блоге: 2
12.03.2011, 13:46  [ТС]     Теория плагинов #14
есть базовый тип для плагинов:
C++
1
2
3
4
5
struct plugin_object {
   virtual const char* name() const = 0;
   virtual const char* description() const { return "null"; }
   virtual const char* version() const { return "null"; }
};
далее я наследуюсь от него и реализую собственный тип.
C++
1
2
3
4
5
6
7
8
9
10
11
12
struct type1: plugin_object {
   type1();
   virtual const char* name() const;
   virtual const char* description() const;
   virtual const char* version() const;
   
   void set(int);
   int get() const;
   
private:
   int val;
};
реализация в .cpp фале. ее приводить не буду. ничего интересного в ней нет.

собираю плагин так:
> g++ -fPIC -c test.cpp
> g++ -shared test.o -o test.so
тестовое приложение выглядит так:
C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
int main(int argc, char** argv) {
   plugin_loader plugin("test.so");
   plugin_object* obj = plugin.instance();
 
   std::cout
   << "name: " << obj->name() << std::endl
   << "description: " << obj->description() << std::endl
   << "version: " << obj->version() << std::endl;
 
   type1* t1 = static_cast<type1*>(obj);
   int v = t1->get();
   std::cout << "v = " << v << std::endl;
   t1->set(33);
   v = t1->get();
   std::cout << "v = " << v << std::endl;
}
при линковке получаю это:
undefined reference to `type1::get() const'
undefined reference to `type1::set(int)'
undefined reference to `type1::get() const'
оно и понятно, еще несколько моментов необходимо знать:
1) методы реализаций должны быть виртуальными.
т.е. в наши методы get() и set() нужно добавить спецификатор virtual.

2) в хидере, не пишите реализацию, т.к. в таком случае, компилятор будет использовать ее, и получится каша
пример:
C++
1
2
3
4
5
6
7
8
9
10
11
12
struct type1: plugin_object {
   type1();
   virtual const char* name() const;
   virtual const char* description() const;
   virtual const char* version() const;
   
   virtual void set(int);
   virtual int get() const { return 44; }
   
private:
   int val;
};
при вызове метода get() из тестового приложения, вы вне зависимости от реализации в .so файле, получите как результат 44
Evg
Эксперт С++Автор FAQ
 Аватар для Evg
16935 / 5340 / 328
Регистрация: 30.03.2009
Сообщений: 14,349
Записей в блоге: 26
12.03.2011, 14:19     Теория плагинов #15
В твоём примере главная программа использует тип type1, который реализован в плагине. Т.е. программа должна "знать" о плагине, что, мягко говоря, делает твой плагин не плагином, а частью программы
niXman
Эксперт C++
 Аватар для niXman
3133 / 1445 / 49
Регистрация: 09.08.2009
Сообщений: 3,441
Записей в блоге: 2
12.03.2011, 14:30  [ТС]     Теория плагинов #16
Цитата Сообщение от Evg Посмотреть сообщение
Т.е. программа должна "знать" о плагине
она должна знать только интерфесы. ничего более.
Evg
Эксперт С++Автор FAQ
 Аватар для Evg
16935 / 5340 / 328
Регистрация: 30.03.2009
Сообщений: 14,349
Записей в блоге: 26
12.03.2011, 14:49     Теория плагинов #17
Цитата Сообщение от niXman Посмотреть сообщение
она должна знать только интерфесы. ничего более.
Интерфейсом должен служить класс plugin_object, а не type1. Плагин должен обладать тем свойством, что он может быть написан после того, как программа создана, а добавление плагина не должно вызывать перекомпиляцию программы. В твоём случае это не так, т.к. программа использует type1, о котором в момент написания программы не должно быть известно ничего

Добавлено через 55 секунд
Методы Set и Get вываливаются за рамки интерфейса, но ты их используешь в главной программе
niXman
Эксперт C++
 Аватар для niXman
3133 / 1445 / 49
Регистрация: 09.08.2009
Сообщений: 3,441
Записей в блоге: 2
12.03.2011, 14:57  [ТС]     Теория плагинов #18
мы говорим о разном.

plugin_object - это базовый абстрактный тип. он нужен для того, чтоб обязать кодера переопределить его методы.
plugin_loader::instance() - возвращает указатель на базовый тип. это нужно для того чтоб можно было получить информацию о плагине.
type1 - это и есть реализация, которая определяет поведение плагина. в данном примере, она варит плюшки. так же, в приложение я могу добавить плагин который будет жарить пельмени.

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

Добавлено через 55 секунд
другими словами: это типичный динамический полиморфизм.
Iron Bug
22 / 22 / 0
Регистрация: 06.12.2010
Сообщений: 125
12.03.2011, 15:44     Теория плагинов #19
видимо, надо мне взять и написать howto по теме экспорта-импорта.
у меня реализована софтина, которая тащит функции из подгружаемых динамически (через dlopen и LoadLibrary, софтина кроссплатформенная) библиотек. причём кроме простого подтаскивания там ещё реализован механизм наследования всех "плагинов" от одной общей динамической библиотеки, в которой сосредоточено "дефолтное" поведение классов.
всё это работает, но настроек дофига и мне нужно собраться и просто взять и написать, что и как.
а так, если это С++, то классы экспортировать можно. есть некоторые проблемы с экспортом-импортом классов между разными компиляторами(и, увы, они неразрешимы). но если планируется, что юзеры будут использовать совместимые на уровне name mangling компиляторы (например, семейство gcc и icc), то можно не париться и смело экспортировать классы. разница только в этом.
тем не менее, даже в случае разных компиляторов классы можно использовать: создать в библиотеке фабрику для создания представителя класса и возвращать указатель на готовый объект. только уничтожаться он также должен в библиотеке. я просто делаю две функции: создать элемент класса и уничтожить его и через вызовы получаю указатель и работаю с ним.
собственно, если есть конкретные вопросы, я могу поковырять код и сказать, что к чему. у меня была мысль сделать небольшую статью на эту тему, про грабли и варианты их обхода, но пока просто не хватает времени, ибо пишу огромный и сложный проект.
MoreAnswers
Эксперт
37091 / 29110 / 5898
Регистрация: 17.06.2006
Сообщений: 43,301
12.03.2011, 16:32     Теория плагинов
Еще ссылки по теме:

C++ Теория по С++
Реализовать систему плагинов (модулей), каждый из которых должен работать в отдельном потоке C++
Взаимодействие плагинов с ядром C++ Linux
Теория по С++ C++
Система плагинов C++

Искать еще темы с ответами

Или воспользуйтесь поиском по форуму:
Evg
Эксперт С++Автор FAQ
 Аватар для Evg
16935 / 5340 / 328
Регистрация: 30.03.2009
Сообщений: 14,349
Записей в блоге: 26
12.03.2011, 16:32     Теория плагинов #20
Цитата Сообщение от niXman Посмотреть сообщение
при помощи plugin_loader::instance() я получаю указатель на базовый тип, и могу его кастовать к нужному
К какому нужному? main - это твоя программа. В момент её написания плагина ещё нет, а следовательно, типа type1 тоже нет. Как ты напишешь программу с использованием несуществующего типа?

Добавлено через 2 минуты
Iron Bug, тут немного не то. Человека заклинило на мысли, что нужно экспортировать класс, а не методы класса (что есть на самом деле функции). Ну нельзя в Си++ экспортировать тип в нормальном понимании этого слова. Теоретически это сделать можно, но это будет не тип языка Си++, а тип некоего виртуального интерпретатора, который будет включен в компилятор

Добавлено через 3 минуты
niXman, пойми ты простую вещь: плагин должен подключаться к программе без перекомпиляции этой самой программы. В противном случае это не плагин, а обычный кусок программы, реализованный в виде динамической библиотеки
Yandex
Объявления
12.03.2011, 16:32     Теория плагинов
Ответ Создать тему
Опции темы

Текущее время: 18:49. Часовой пояс GMT +3.
КиберФорум - форум программистов, компьютерный форум, программирование
Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2017, vBulletin Solutions, Inc.
Рейтинг@Mail.ru