Показать полную графическую версию : Система плагинов для программы на с++
crashtuak
15-04-2012, 20:12
Для программы нужно создать систему плагинов. Плагины должны представлять из себя обычный текст. При запуске программы нужно скомпилировать все плагины в нативный код. Сама программа написана на с++. Смотрел в сторону LUA, и в часности на LuaJIT, но там нету быстрой и легкой интеграции в с++ код(хотя вызвать чисто сишные методы легко). Собственно нужна легкая интеграция с с++, ООП, и главное-компиляция(в приложении очень важна скорость, и количество потребляемой памяти). Также было бы круто иметь синтаксис как в Java или С#. Как для моих целей может подойти Google V8(там все идеально, только не уверен за скорость)?
Посоветуйте что нибуть нормальное и быстрое.
Плагины в виде библиотек рассматривались? (компиляция в нативный код компилятором)
crashtuak
06-05-2012, 20:37
Плагины в виде библиотек рассматривались » Та хоть в яблоках или апельсинах :) . Главное что бы работало быстро, памяти ело мало... Скорость первого запуска плагина не важна(то есть, имеем кучу новых плагинов, запускаем приложение, магия магия магия, две, три, четыре минуты магии, и вот оно-приложение работает быстро и без тормозов:)). Уже вроде бы присмотрел несколько вариантов... Первый, более простой, прикрутить MONO к приложению (кроме самого MONO получаем кучу дополнительных бонусов). Второй вариант-собрать на основе cygwin или mingw свой маленький компилятор, допилить нужные функции, выпилить не нужные (скорость в итоге будет выше всего, но и танцев побольше будет). На относительно второго варианта не очень уверен, не знаю, как код с++ скомпиленый mingw(cygwin) подружится с приложением на msvc... Вообщем, предлагайте варианты, буду рад услышать советы.
зачем собирать компилятор? чем mingw не компилятор то? Перед запуском выполняешь g++ -shared plugin.cpp -o plugin.dll (или как-то так) и вперёд... Быстрее скомпилированного гецецой кода ничего не будет работать.
Как вариант - собирать объектники и линковать результирующий код. В общем получится что-то генту-подобное. Конечно, вместе с исходниками или объектниками нужно тогда поставлять mingw.
crashtuak
08-05-2012, 12:45
Ну, в с++ я не мастер, так что вопрос, при g++ -shared plugin.cpp -o plugin.dll будет прилинкована стандартная библиотека с++ к dll?
g++ аналогичен по действию gcc -lstdc++ и ещё реакцией на расширения файлов.
Можно почитать здесь http://parter.kaist.ac.kr/man/g++.html (найдено гуглением man g++)
прилинкована стандартная библиотека с++ к dll? »
да, это и есть -lstdc++
crashtuak
09-05-2012, 17:51
Вариант с mingw может прокатить только если остальное приложение будет на основе mingw, а то физическое представление объекта компилятора mingw может отличатся от такового у msvc. Еще беда в том, что либу от mingw к msvc будет проблемно прикрутить. То есть, надо будет извращаться, делать либо сишный интерфейс, либо долго и муторно искать способ подружить два компилятора.
если бы не библиотека с закрытым кодом в приложении, без которой никак, и которая собрана под msvc, я б не парился и все на mingw сделал бы :(
варианты:
1) msvc-шную часть скомпилировать при помощи gcc (и она станет gcc-шной)
2) msvc-шную часть скомпилировать в dll и подключать эту dll при сборке в gcc
3) в msvc-шной части сделать обзор dll-ок из папки /plugin и вызывать у каждой найденной какую-нить функцию (так делает большинство серьёзных программ), а dll-ки подкладывать в папку после сборки при помощи gcc
если бы не библиотека с закрытым кодом в приложении »
тут по ходу дела вариант 2.
либу от mingw к msvc будет проблемно прикрутить »
DLL прикрутить значительно проще.
Хотя у меня был случай, когда надо было сделать плагин, у которого в аргументах интерфейсных функций была паскалевская строка. Сделать его на c++ я не осилил, пришлось использовать delphi
© OSzone.net 2001-2012
vBulletin v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.