Нормальное встраивание scripting engine в твердотельный код есть неизбывная мечта человечества.
Но очевидно что ёж и трепетная лань плохо агрегируются — разные модели и времена жизни объектов: scripting это как правило GC тогда
как в С/C++ все гвоздями прибито.

А расскажите кто какие удачные (удобные, эффективные ) решения видел?

Например про LUA знаю, но сильно удачным ейное решение не считаю. Слишком много деталей про устройство VM и размещение на стеке всего хозяйства нужно знать на C/C++ стороне.

Python в принципе должен иметь что-то более удобное ибо в нем GC в классическом понимании нет. Т.е. по идее в нем объект раз созданный по памяти не гуляет. Т.е. вполне себе можно в C/C++ с ним работать напрямую (я могу ошибаться про Питон).

В принципе IActiveScripting со товарищи и с поддержкой на уровне IDE ActiveX в принципе может считаться чем-то близким к идеалу.
Но это все требует значительной инфраструктуры в виде COM. Т.е в качестве встраиваемого in-proc only взаимодествия не сильно подходит.
В принципе там же и Objective-C со своим runtime.

Наверное таки идеала для голого C/C++ нет... или есть?
Может JNI от Java близко к тому?

Здравствуйте, c-smile, Вы писали:

CS>Наверное таки идеала для голого C/C++ нет... или есть?
CS>Может JNI от Java близко к тому?
JNI наиболее корректна в том смысле, что позволяет работать даже с учётом параллельного упаковывающего GC. Это автоматически означает отсутствие прямого доступа к данным.

Можете поглядеть guile scheme (http://www.gnu.org/software/guile/guile.html, тут мануал неплохой: http://lonelycactus.com/guilebook/book1.html). Не знаю, понравится ли оно Вам — но вроде особых заморочек с GC и внутренностями интерпретатора там нет. Нет, правда, и прозрачного преобразования между типами данных — т.е. Ваш C/C++ код должен будет заботиться о том, что за объекты ему подсунул интерпретатор и какие объекты интерпретатору передать.

Здравствуйте, c-smile, Вы писали:

может Squirrel подойдёт?

Здравствуйте, c-smile, Вы писали:

CS>А расскажите кто какие удачные (удобные, эффективные ) решения видел?

Я вам советую скачать SWIG, зайти в 'share/swig' и сравнить как выглядят сишные swg-файлы для полутора десятков языков (c#, java, lua, mzscheme, ocaml, perl, php, python, ruby, tcl, etc).

Что касается Lua — да API достаточно низкоуровневое зато абсолютно гибкое. Для неискушенных пользователей всегда можно завернуть во что-то попроще:

// LuaPlus
ScriptRegisterMemberDirect(m_L, "DebugOut", this, MyWindow::DebugOut);

Здравствуйте, c-smile, Вы писали:

CS>Нормальное встраивание scripting engine в твердотельный код есть неизбывная мечта человечества.
CS>Но очевидно что ёж и трепетная лань плохо агрегируются — разные модели и времена жизни объектов: scripting это как правило GC тогда
CS>как в С/C++ все гвоздями прибито.

В интернетах есть такая статья C APIs in Extension and Extensible Languages от авторов Луа. Возможно будет интересно прочитать их мнение.

Здравствуйте, z00n, Вы писали:

Z>Здравствуйте, c-smile, Вы писали:

CS>>А расскажите кто какие удачные (удобные, эффективные ) решения видел?

Z>Я вам советую скачать SWIG, зайти в 'share/swig' и сравнить как выглядят сишные swg-файлы для полутора десятков языков (c#, java, lua, mzscheme, ocaml, perl, php, python, ruby, tcl, etc).

Про Swig я знаю с самого его начала. Это несколько иное.
Swig это несколько более высокоуровневая абстракция сама использующая С API.

Мой вопрос состоит в именно в дизайне самого С/C++ API.

Z>Что касается Lua — да API достаточно низкоуровневое зато абсолютно гибкое. Для неискушенных пользователей всегда можно завернуть во что-то попроще:
Z>

Z>// LuaPlus
Z>ScriptRegisterMemberDirect(m_L, "DebugOut", this, MyWindow::DebugOut);
Z>

Как я уже сказал Lua подход я знаю. Гибкость подхода сильно ограничена необходимостью работать через стек VM.
Что конечно эффективно, но уж слишком низкоуровнево.

Хочется чего-то более human readable.
В принципе есть boost::python как попытка сделать сие.
Но порог входа на самом деле не сильно отличается от cкажем LUA API (по количеству абстракций требующих знания)

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, c-smile, Вы писали:

А>может Squirrel подойдёт?

squirrel в общем-то тоже не сильно от LUA отличается в плане API

Вот пример из документации ( http://squirrel-lang.org/doc/squirrel2.html#d0e3752 )

SQInteger register_global_func(HSQUIRRELVM v,SQFUNCTION f,const char *fname)
{
    sq_pushroottable(v);
    sq_pushstring(v,fname,-1);
    sq_newclosure(v,f,0,0); //create a new function
    sq_createslot(v,-3); 
    sq_pop(v,1); //pops the root table    
}

Что в общем-то даже более тоскливее чем:

  lua_pushcfunction(L, fname);
  lua_setglobal(L, fname);

Здравствуйте, c-smile, Вы писали:

CS>Про Swig я знаю с самого его начала. Это несколько иное.
CS>Swig это несколько более высокоуровневая абстракция сама использующая С API.

Я вам посоветовал не SWIG посмотреть, а примеры применения С-API соответственных языков, которые внутри реализации SWIG хранятся в файлах '.swg'.

CS>Как я уже сказал Lua подход я знаю.
CS>Гибкость подхода сильно ограничена необходимостью работать через стек VM.
Как страдает гибкость при таком подходе? Можно пример?
Я считаю, что наоборот, подход абсолютно гибкий , но не самый наглядный.

CS>Что конечно эффективно, но уж слишком низкоуровнево.
CS>Хочется чего-то более human readable.
CS>В принципе есть boost::python как попытка сделать сие.

Чем LuaPlus(и все другие с++ шаблонные враперы) не попытка?

// LuaPlus (еще раз)
ScriptRegisterMemberDirect(m_L, "DebugOut", this, MyWindow::DebugOut);

Где тут стек VM?

Здравствуйте, c-smile, Вы писали:

CS>squirrel в общем-то тоже не сильно от LUA отличается в плане API
у них есть обертка SqPlus
я её использую и очень редко вспоминаю о стеках и прочем

Z>Чем LuaPlus(и все другие с++ шаблонные враперы) не попытка?

Меня вот luabind устроил.

Здравствуйте, c-smile, Вы писали:

CS>Нормальное встраивание scripting engine в твердотельный код есть неизбывная мечта человечества.
CS>Но очевидно что ёж и трепетная лань плохо агрегируются — разные модели и времена жизни объектов: scripting это как правило GC тогда
CS>как в С/C++ все гвоздями прибито.

CS>А расскажите кто какие удачные (удобные, эффективные ) решения видел?

Не знаю, насколько это удобно но perlembed/perlguts имхо довольно эффективно.