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

CS>>Не было такого.

K>Мне сказали что с тобой связывались. Объяснили причину почему не договорились.
K>Человек с инициалами AA мой superviser. Возможно на самом деле с тобой общался кто и повыше, не знаю.

Для тех кто следит за интригой: все, разобрались

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

Вот еще вспомнил:

В DDJ была опубликована статья о языке BOB от David Betz:
http://terrainformatica.com/org/bob_article.htm

Сгрузить можно здесь:
http://www.mv.com/ipusers/xlisper/bob.zip

В принципе tiscript это во многом bob.

Т.е. если кто-то хочет построить свой язык с C++/Java нотацией то это хороший старт.

В bob есть все что нужно — компилятор,VM и GC.

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

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

CS>>PS: Spider Monkey можно не смотреть. Старый проект — куча культурных слоев. Расширямости — ноль.
CS>>Также не надо смотреть на KDE JS (http://developer.kde.org/documentation/library/3.0-api/classref/kjs/)
CS>>и SEE: Simple ECMAScript Engine (http://www.adaptive-enterprises.com.au/~d/software/see/)
CS>>ибо писано это детьми Герберта Шилдта в стиле наивной прямой интепретации source code — "что вижу то пою".

K>А чем дети Шилдта отличаются?

Есть три способа интерпретации:

1) прямая, синтаксический разбор совмещен с исполнением:

void eval_exp1(int *value)
{
  eval_exp2(value); 
  op = *token;
  if(strchr(relops, op)) {
    get_token(); 
    eval_exp2(&partial_value); 
    switch(op) {  /* perform the relational operation */
      case LT: 
        *value = *value < partial_value;
        break;
      case GT:
        *value = *value > partial_value;
        break;
    }
  }
}

(это фрагмент Little-C из книжки Шилдта)

2) компиляция в и прямая интерпретация syntax tree.

node* parse_exp1()
{
  node* n1 = parse_exp2(); 
  op = *token;
  if(strchr(relops, op)) {
    get_token(); 
    node* n2 = parse_exp2(); 
    return new relation_node(op , n1, n2);
  }
  return n1;
}

value eval_relation_node(relation_node* n)
{
    switch(n->op) {  /* perform the relational operation */
      case LT: 
        return eval(n->left) < eval(n->right);
      case GT:
        return eval(n->left) > eval(n->right);
    }
}

Это в общем-то вариация метода 1.

3) компиляция в байткод и исполнение байткода на стеке:

void parse_exp1(bytecodes)
{
  parse_exp2(value); 

  byte bc; 
  switch(get_token()) 
  {  /* perform the relational operation */
      case '<': 
        bc = CODE_LT; break;
      case '>':
        bc = CODE_GT; break;
      default: 
        push_back_token();
        return;
  }
  bytecodes.append(CODE_PUSH);
  parse_exp2(bytecodes); 
  bytecodes.append(bc); 

}

value exec(bytecodes)
{
    byte* pc = &bytecodes[0];
    for(;;) /* for all bytecodes */
    {
        switch(*pc) 
        {  
          ... 
          case CODE_LT: v = *stack[1] < *stack[0]; --stack; *stack = t; ++pc; break;
          case CODE_GT: v = *stack[1] > *stack[0]; --stack; *stack = t; ++pc; break;
        }
    }
}

Третий метод самый правильный — в смысле эффективный, поддается формальной оптимизации и не
использует C stack.

1 или 2 метод используют KJS, SEE и по-моему Mozilla (уже не помню)
3 метод используют NJS, DMDScript, MS JS (по косвенным данным), BOB, c-smile, tiscript.

Вот примерно так.

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

K>Здравствуйте,
K>мне нужно принять решение какой scripting engine использовать в проекте.
K>Прошу у вас совета.
Предлагаю посмотреть на http://www.angelcode.com/angelscript
K>Требования такие:
K>1. Кроссплатформенность
Есть такое свойство.
K>2. Работа с ECMAScript, но с возможностью расширения до синтаксиса близкого к C#
Это не совсем. Синтаксис C-подобен, но не ECMAScript. Лицензия — BSD-style, написан на C++. Так что доработать, наверное, можно. Только вот не могу сказать, каких усилий это потребует.
K>3. Лёгкость интегрирования в существующий C++ проект
Интегрируется не просто просто, а очень просто. Проще не видел.
K>4. Лёгкость самого scripting engine, то есть малый размер и скорость работы.
Он типизированный. С одной стороны, он благодаря этому быстрее работает, с другой стороны, в скриптах как-то непривычно типизировать переменные.
K>Спасибо.
Рад, если помог.

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

K>Здравствуйте,

K>мне нужно принять решение какой scripting engine использовать в проекте.
K>Прошу у вас совета.

K>Требования такие:

K>1. Кроссплатформенность
K>2. Работа с ECMAScript, но с возможностью расширения до синтаксиса близкого к C#
K>3. Лёгкость интегрирования в существующий C++ проект
K>4. Лёгкость самого scripting engine, то есть малый размер и скорость работы.
(от себя) безопасность хост-программы

здесь описывается скриптовый язык, очень хорошо интегрирующийся в С++ — http://www.livejournal.com/users/_winnie/4401.html
ну и далее по ссылкам —
http://www.gamedev.ru/forum/?group=0&topic=20087
http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html
ну и поиск по форуму — http://rsdn.ru/search/?q=yield_return&mode=rank&group=N

K>Спасибо.

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

GS>>Если тебе нужна поддержка COM, то я бы использовал ActiveScript. Собственно говоря, я другой просто не знаю.

AS>Это проблематично, поскольку придется писать кучу COM врапперов и иметь проблемы с контролем времени жизни объектов,

Придется. COM-ли врапперов, или врапперов для другого скриптинга. Проблемы c контролем времени жизни преувеличены. Достаточно их просто привязать смарт-пойнтерами к объектам скриптинга.

AS>либо вообще делать все внутри в виде интерфейсов.

Да. Но кто ж знал заранее...

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

Я сейчас занимаюсь чем-то подобным. Имею ужасающий код в который нужно впыжить скриптинг. Сделано, в конце концов, так: выписан промежуточный абстрактный слой (см. сигу Анатоликса), этот промежуточный абстрактный слой определяет объектную модель, экспортируюмую в скриптинг, и используется в качестве метаданных при генерации врапперов. Врапперы генерируются одновременно и для ActiveScript и для SpiderMonkey.

ActiveScript очень удобен тем, что его можно дебагать на скриптовом уровне. Также можно переключиться, к примеру, c jscript на vbscript. Также влегкую реализовался внешний скриптинг и вообще управление приложением извне по COM интерфейсам.

То есть получается (мета)программироваие на смеси XSLT/C++/JavaScript.

AS>Именно это и нужно. Приложение представляет некоторые базовые сервисы (которые обязаны быть производительными), а остальное — собстственно всю логику работы приложения — определяет скрипт.

Какое-то время назад это было прогрессивной идеей Но почему-то не прижилось, не знаю почему — не отслеживал историю вопроса .

AS>В связи с чем, кстати, вопрос. Как удобнее работать с гуем из скрипта? Пока мне надумался вариант создавать объект HTML-DOM, и уже в нем делать диалоги для общения с пользователем. Однако это... несколько муторно.

Делать интерфейс на HTML — вполне себе ничего решение, но имеет как свои плюсы так и свои минусы.

Из плюсов:

1. Это красиво. Любой мало-мальски неплохой HTML дизайнер нарисует тебе такой интерфейс — закачаешься, ручками (в смысле, owner-draw controls) такой рисовать оччень долго, муторно, к тому же сопряжено с геммороем типа поддержки 9x и т.п.
2. Это супергибко. Сделать приложение skinable — очень легко и просто, поддержать несколько интерфейсов (типа, для продвинутых юзеров, для домохозяек, для прапорщиков) — запросто.
3. Это дёшево Рисовать интерфейс в HTML может HTML artist, не надо тратить время на то чтобы перенести "художественности" которые нарисовал дизайнер на owner-draw контролы.
4. Что ещё... А, очень хорошо проходит разделение на document-view — всё что касается данных пишешь на C++ (ну, или если очень хочется — на чём угодно другом), а весь интерфейс с рюшечками — на JavaScript (вариант — VBScript) и HTML.

Из минусов:

1. HTML имеет свои ограничения. К примеру, ты не можешь сделать длинный список — будет подтормаживать HTML рендеринг. Приходится либо заморачиваться на ActiveX список, либо бить длинный список на страницы.
2. MSHMTL — большая и сложная система. Рано или поздно ты начнёшь воевать с ней — бороться с её глюками, с её secuity, с различиями между версиями и т.п.

Здравствуйте,

мне нужно принять решение какой scripting engine использовать в проекте.
Прошу у вас совета.

Требования такие:
1. Кроссплатформенность
2. Работа с ECMAScript, но с возможностью расширения до синтаксиса близкого к C#
3. Лёгкость интегрирования в существующий C++ проект
4. Лёгкость самого scripting engine, то есть малый размер и скорость работы.

Спасибо.

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

K>Здравствуйте,

K>мне нужно принять решение какой scripting engine использовать в проекте.
K>Прошу у вас совета.
Qt Script for Applications
здесь

K>Требования такие:
K>1. Кроссплатформенность
Да еще какая!
K>2. Работа с ECMAScript, но с возможностью расширения до синтаксиса близкого к C#
С ECMAScript работает, насчет С# не уверен
K>3. Лёгкость интегрирования в существующий C++ проект
Сам только сегодня обнаружил... Если проект пишется на Qt, то да, а если не на нем, то не знаю.
K>4. Лёгкость самого scripting engine, то есть малый размер и скорость работы.
И это есть

K>Спасибо.

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

K>мне нужно принять решение какой scripting engine использовать в проекте.
Пока такого выбора делать не приходилось, но вполне возможно предстоит в будующем.

В гейм-деве бешенной популярностью пользуется Lua

K>Требования такие:
K>1. Кроссплатформенность
[LuaCheia] (5.0) — Lua 5.0 for GNU/Linux, Mac/OS X, Windows, *BSD, Solaris, etc. Includes many add-on binary modules.

K>2. Работа с ECMAScript, но с возможностью расширения до синтаксиса близкого к C#


K>3. Лёгкость интегрирования в существующий C++ проект
Судя по кол-ву инструментов (http://lua-users.org/wiki/LuaAddons, раздел Code wrappers) — не проблема

K>4. Лёгкость самого scripting engine, то есть малый размер и скорость работы.
http://en.wikipedia.org/wiki/Lua_programming_language#Philosophy

In general, Lua strives to provide flexible meta-features that can be extended as needed, rather than supply a featureset specific to one programming paradigm. As a result, the base language is light—in fact, the full reference interpreter is only about 150KB compiled—and easily adaptable to a broad range of applications.

Если правильно понимаю, следующая фича имела под собой целью повысить скорость работы (за что и пользуется таким успехом у гейм-девелоперов)
http://en.wikipedia.org/wiki/Lua_programming_language#Internals

Lua programs are not interpreted directly, but are compiled to bytecode which is then run on the Lua virtual machine. The compilation process is typically transparent to the user and is performed during run-time, but it can be done offline in order to increase performance or reduce the memory footprint of the host environment by leaving out the compiler.

Дополнительные бонусы:
Что не может не радовать:

License for Lua 5.0 and future versions:
Starting with Lua 5.0, Lua is licensed under the terms of the MIT license reproduced below.

Используется в куче проектов, что автоматически означает:
1. стабильность
2. наличие комьюнити
3. богатый инструментарий

---

http://lua-users.org/wiki/
http://en.wikipedia.org/wiki/Lua_programming_language

А вообще, судя по http://en.wikipedia.org/wiki/Category:Scripting_languages и http://www.mvps.org/scripting/languages/ выбор предстоит непростой

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

K>2. Работа с ECMAScript, но с возможностью расширения до синтаксиса близкого к C#

Вроде как вот эти кандидатуры подходят:
TIScript от небезызвестного тебе c-smile
DMDScript от автора языка D и компилятора Digital Mars C++ (но платное).

Если же не нужна ECMAScript, то можно рассмотреть множество скриптовых языков: Lua, Python, Ruby -- они все кроссплатформенные и внедряются в C++ проекты.

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

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

K>>2. Работа с ECMAScript, но с возможностью расширения до синтаксиса близкого к C#

E>Вроде как вот эти кандидатуры подходят:
E>TIScript от небезызвестного тебе c-smile
E>DMDScript от автора языка D и компилятора Digital Mars C++ (но платное).

E>Если же не нужна ECMAScript, то можно рассмотреть множество скриптовых языков: Lua, Python, Ruby -- они все кроссплатформенные и внедряются в C++ проекты.

Если не считать что TIScript это "черный ящик" (исходники к нему не прилагаются) то выглядит неплохо.

От себя хотел добавить, что за 3 года с луа 5 проблем там не обнаружил.
Но если программировать скрипты придется самому то душа просит что нить более объектно-ориентированное

wbr

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

SD>От себя хотел добавить, что за 3 года с луа 5 проблем там не обнаружил.
SD>Но если программировать скрипты придется самому то душа просит что нить более объектно-ориентированное

Объектно-ориентированность в Луа находится на вполне достаточном уровне. При наличии хорошей обертки. См., например, luabind. Там есть даже "наследование" от классов С++.

Tuo_Bellas.

Python

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

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

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

K>>>2. Работа с ECMAScript, но с возможностью расширения до синтаксиса близкого к C#

E>>Вроде как вот эти кандидатуры подходят:
E>>TIScript от небезызвестного тебе c-smile
E>>DMDScript от автора языка D и компилятора Digital Mars C++ (но платное).

E>>Если же не нужна ECMAScript, то можно рассмотреть множество скриптовых языков: Lua, Python, Ruby -- они все кроссплатформенные и внедряются в C++ проекты.

SD>Если не считать что TIScript это "черный ящик" (исходники к нему не прилагаются) то выглядит неплохо.

На самом деле исходники доступны но они не open source. Не все заказчики любят это дело.

SD>От себя хотел добавить, что за 3 года с луа 5 проблем там не обнаружил.
SD>Но если программировать скрипты придется самому то душа просит что нить более объектно-ориентированное


tiscript это prototype based язык/runtime
что есть хорошо и что есть плохо:

например такие трюки как:

var myobject = new Class1();
myobject.method1();
...
myobject.class = Class2; 
myobject.method1(); // уже другой метод совсем.

работают. Т.е. имеем эдакий динамический полиморфизм.
Иногда черезвычайно удобно. Но иногда можно нарваться на
"крякает но не утка" (это про duck typing).

язык c-smile в принципе более строгий — у него классы настоящие.
т.е. в каком-то смысле он ближе к C# и совсем близок к JavaScript v.2.0.

Что лучше надо смотреть по задаче.
Для web'a javascript (v.1.*, prototype based) практически идеален.





SD>wbr

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

K>Здравствуйте,

K>мне нужно принять решение какой scripting engine использовать в проекте.
K>Прошу у вас совета.

Всем спасибо за ответы.
Теперь надо найти время чтобы всё это просмотреть и сделать выбор. На днях займусь.

Мы уже хотели использовать tiscript, но нам нужны исходники.
Начальство недавно связывалось с c-smile, но видно как раз из-за лицензии не получилось.

Здравствуйте.

Есть движок от Mozilla: SpiderMonkey JavaScript.
Не знаю, почему его забыли. Вполне себе вещь.

Из минусов:
Не уверен на счёт С#-подобного синтаксиса.

здесь.

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

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

K>>Здравствуйте,

K>>мне нужно принять решение какой scripting engine использовать в проекте.
K>>Прошу у вас совета.

K>Всем спасибо за ответы.
K>Теперь надо найти время чтобы всё это просмотреть и сделать выбор. На днях займусь.

K>Мы уже хотели использовать tiscript, но нам нужны исходники.
K>Начальство недавно связывалось с c-smile, но видно как раз из-за лицензии не получилось.

Как инициалы начальника? Не АШ случайно?
Там единственная проблема — сугубо организционная — установка SVN и все такое.

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

CS>Как инициалы начальника? Не АШ случайно?

Нет. Инициалы — АА.

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

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

CS>>Как инициалы начальника? Не АШ случайно?

K>Нет. Инициалы — АА.

Не было такого.

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

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

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

CS>>>Как инициалы начальника? Не АШ случайно?

K>>Нет. Инициалы — АА.

CS>Не было такого.

Мне сказали что с тобой связывались. Объяснили причину почему не договорились.
Человек с инициалами AA мой superviser. Возможно на самом деле с тобой общался кто и повыше, не знаю.

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

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

CS>>>Не было такого.

K>>Мне сказали что с тобой связывались. Объяснили причину почему не договорились.
K>>Человек с инициалами AA мой superviser. Возможно на самом деле с тобой общался кто и повыше, не знаю.

CS>Для тех кто следит за интригой: все, разобрались

я так и не понял : так есть от tiscript исходники или нет ?
или на каких доп условиях?

wbr

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

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

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

CS>>>>Не было такого.

K>>>Мне сказали что с тобой связывались. Объяснили причину почему не договорились.
K>>>Человек с инициалами AA мой superviser. Возможно на самом деле с тобой общался кто и повыше, не знаю.

CS>>Для тех кто следит за интригой: все, разобрались

SD>я так и не понял : так есть от tiscript исходники или нет ?
SD>или на каких доп условиях?

Доп. условий два:

1) написать мне письмо.
2) не публиковать в открытом доступе. Мотивы я изложил — не хочу потом с лицензиями разбираться — муторно очень.


SD>wbr

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

http://www.mozilla.org/js/spidermonkey

Удовлетворяет всем пунктам.

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

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

N>http://www.mozilla.org/js/spidermonkey

N>Удовлетворяет всем пунктам.

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

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

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

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

N>>http://www.mozilla.org/js/spidermonkey

N>>Удовлетворяет всем пунктам.

K>Спасибо.
K>Правда этот движок уже здесь упоменался.
K>Слышал, что тормозной он. В любом случае надо проверять.

Павел, в вашем случае в первую очередь должна интересовать лицензия.
MPL не подходит насколько я знаю для вас.

Боюсь как бы вообще не с нуля все писать придется.

PS: Spider Monkey можно не смотреть. Старый проект — куча культурных слоев. Расширямости — ноль.
Также не надо смотреть на KDE JS (http://developer.kde.org/documentation/library/3.0-api/classref/kjs/)
и SEE: Simple ECMAScript Engine (http://www.adaptive-enterprises.com.au/~d/software/see/)
ибо писано это детьми Герберта Шилдта в стиле наивной прямой интепретации source code — "что вижу то пою".

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

CS>PS: Spider Monkey можно не смотреть. Старый проект — куча культурных слоев. Расширямости — ноль.
CS>Также не надо смотреть на KDE JS (http://developer.kde.org/documentation/library/3.0-api/classref/kjs/)
CS>и SEE: Simple ECMAScript Engine (http://www.adaptive-enterprises.com.au/~d/software/see/)
CS>ибо писано это детьми Герберта Шилдта в стиле наивной прямой интепретации source code — "что вижу то пою".

А чем дети Шилдта отличаются?

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


CS>Третий метод самый правильный — в смысле эффективный, поддается формальной оптимизации и не
CS>использует C stack.

CS>1 или 2 метод используют KJS, SEE и по-моему Mozilla (уже не помню)
CS>3 метод используют NJS, DMDScript, MS JS (по косвенным данным), BOB, c-smile, tiscript.


В Mozilla JS (по крайней мере в последней версии) используется как раз 3-й подход. Т.е. компиляция в байткод. Там можно явно скомпилировать скрипт, и потом многократно его вызывать на исполнение.

IMHO Mozilla — это как раз оптимальный выбор.

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

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


CS>>Третий метод самый правильный — в смысле эффективный, поддается формальной оптимизации и не
CS>>использует C stack.

CS>>1 или 2 метод используют KJS, SEE и по-моему Mozilla (уже не помню)
CS>>3 метод используют NJS, DMDScript, MS JS (по косвенным данным), BOB, c-smile, tiscript.


А>В Mozilla JS (по крайней мере в последней версии) используется как раз 3-й подход. Т.е. компиляция в байткод. Там можно явно скомпилировать скрипт, и потом многократно его вызывать на исполнение.

Да, промашка вышла с моей стороны. Там действиельно BC interpretter.

А>IMHO Mozilla — это как раз оптимальный выбор.

Но, требование
"Работа с ECMAScript, но с возможностью расширения до синтаксиса близкого к C#"
как-то сложно себе представить выполнимым смотря на:
http://lxr.mozilla.org/mozilla/source/js/src/jsinterp.c

Это к вопросу о том что даже имея исходники что либо сделать с ними представляется
нереальным.

-------------

При беглом осмотре там кстати обнаружилось начало E4X имплементации.
E4X это встроенная в язык XML модель.
http://weblog.infoworld.com/udell/2004/09/29.html

Хорошо это или плохо — не знаю.




Там

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

CS>http://lxr.mozilla.org/mozilla/source/js/src/jsinterp.c
...
CS>При беглом осмотре там кстати обнаружилось начало E4X имплементации.

Что значит начало? По моим понятиям оно там (1.5.0.1) все, Брендон — один из замутил этого E4X.

Я сам проверял только что инлайнинг их работает.

CS>Хорошо это или плохо — не знаю.

Вот, кстати, MS собирается-то E4X реализовывать? Я, конечно, понимаю, что в аспекте IDispatch/IDispatchEx им это может быть трудновато, но...

CS>Там

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

K>Здравствуйте,

K>мне нужно принять решение какой scripting engine использовать в проекте.
K>Прошу у вас совета.

K>Требования такие:
K>1. Кроссплатформенность
K>2. Работа с ECMAScript, но с возможностью расширения до синтаксиса близкого к C#
K>3. Лёгкость интегрирования в существующий C++ проект
K>4. Лёгкость самого scripting engine, то есть малый размер и скорость работы.

K>Спасибо.

http://root.cern.ch/root/Cint.html

K>Требования такие:
K>1. Кроссплатформенность
K>2. Работа с ECMAScript, но с возможностью расширения до синтаксиса близкого к C#
K>3. Лёгкость интегрирования в существующий C++ проект
K>4. Лёгкость самого scripting engine, то есть малый размер и скорость работы.

Возник аналогичный вопрос. Требования (1 и 2) не нужно, кроме (3 и 4), нужна поддержка ActiveX\COM объектов а-ля VB или Java скрипт. Безусловно, можно сделать врапперы-интерфейсы для С++ объектов и сделать все на WSH, но как то это муторно, хотелось бы попроще. Может, какие из перечисленных или других скриптовых движков поддерживают ActiveX\COM? Кроме WSH, я других вариантов не нашел

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

K>>Требования такие:
K>>1. Кроссплатформенность
K>>2. Работа с ECMAScript, но с возможностью расширения до синтаксиса близкого к C#
K>>3. Лёгкость интегрирования в существующий C++ проект
K>>4. Лёгкость самого scripting engine, то есть малый размер и скорость работы.

AS>Возник аналогичный вопрос. Требования (1 и 2) не нужно, кроме (3 и 4), нужна поддержка ActiveX\COM объектов а-ля VB или Java скрипт. Безусловно, можно сделать врапперы-интерфейсы для С++ объектов и сделать все на WSH, но как то это муторно, хотелось бы попроще. Может, какие из перечисленных или других скриптовых движков поддерживают ActiveX\COM? Кроме WSH, я других вариантов не нашел

Что-то я тебя не понимаю.

Скриптинг-энжин, это такая штуковина (dll, lib или даже просто cpp), которую всовываешь в проект, и уже можешь исполнять c ее помощью скриптовый код. Так?

Так вот, в микрософтовском подходе (ActiveScript) это разрезано напополам, на Scripting Engine и Scripting Host, причем так, что умея скриптинг-хост ты можешь цеплять к нему по COM-у разные энжины.

Если тебе нужно это всандалить в свой проект, то скриптинг хост либо нужно реализовать самому, либо воспользоваться имеющимся, например Scripting Control.

А WSH — это отдельностоящий хост, включить его в проект на С++ нельзя, в том смысле, что если можно то он будет одельным процессом.

Если тебе нужна поддержка COM, то я бы использовал ActiveScript. Собственно говоря, я другой просто не знаю.

GS>Если тебе нужно это всандалить в свой проект, то скриптинг хост либо нужно реализовать самому, либо воспользоваться имеющимся, например Scripting Control.

GS>А WSH — это отдельностоящий хост, включить его в проект на С++ нельзя, в том смысле, что если можно то он будет одельным процессом.

Имелась в виду реализация своего WSH, конечно. http://gzip.rsdn.ru/article/com/wscript/vstr_WS.xml

Автор(ы):
Дата: 25.04.2001

GS>Если тебе нужна поддержка COM, то я бы использовал ActiveScript. Собственно говоря, я другой просто не знаю.

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

AS>>Это проблематично, поскольку придется писать кучу COM врапперов и иметь проблемы с контролем времени жизни объектов,

GS>Придется. COM-ли врапперов, или врапперов для другого скриптинга. Проблемы c контролем времени жизни преувеличены. Достаточно их просто привязать смарт-пойнтерами к объектам скриптинга.

Например, есть некий класс, в котором есть набор итемов std::vector<CItem *> или std::list<CItem>. Кроме того, на эти же итемы могут ссылаться внешние по отношению к этому объекты. Т.о. для актив скриптинга возникает проблема времени жизни объектов CItem. И сделать это все по-нормальному без переделки CItem на ком интерфейс будет очень непросто — ведь сейчас класс-контейнер контролирует время жизни экземпляра CItem, а для Com время жизни определяется счетчиком ссылок. Плюс возникает проблема эффективного создания подобных объектов. В случае list аллокатор может быть сколь угодно оптимизирован на создание мелких объектов, в отличие от стандартной фабрики интерфейсов, которую я вижу вариант сделать только по new.

Т.о. получается, что если есть хоть какие то минимальные зависимости между объектами, враппер сделать практически невозможно — возникают проблемы времени жизни. Придется именно внутри все делать на интерфейсах. Т.е. полный рефакторинг кода

В том же луа или ангел скрипт эти проблемы решаются генерацией врапперов, причем для сих целей существуют утилиты. Для актив скриптинга я потобных утилит, как ни странно, не обнаружил.

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

GS>>Придется. COM-ли врапперов, или врапперов для другого скриптинга. Проблемы c контролем времени жизни преувеличены. Достаточно их просто привязать смарт-пойнтерами к объектам скриптинга.

AS>Например, есть некий класс, в котором есть набор итемов std::vector<CItem *> или std::list<CItem>. Кроме того, на эти же итемы могут ссылаться внешние по отношению к этому объекты.

Ну вижу проблемы. И в контейнерах, и во внешних объектах держишь смарт-пойнтер.

AS>В том же луа или ангел скрипт эти проблемы решаются генерацией врапперов, причем для сих целей существуют утилиты. Для актив скриптинга я потобных утилит, как ни странно, не обнаружил.

Какие проблемы-то? Че-то я не понял. Утилиты из луа и а.с. я посмотрю, но идею не осознал.

AS>>В том же луа или ангел скрипт эти проблемы решаются генерацией врапперов, причем для сих целей существуют утилиты. Для актив скриптинга я потобных утилит, как ни странно, не обнаружил.

GS>Какие проблемы-то? Че-то я не понял. Утилиты из луа и а.с. я посмотрю, но идею не осознал.

Идея проста — подсунул генератору набор классов — и получил на выходе набор классов, пригодных для скриптинга. Будь это врапперы или же модифицированные исходные классы. Вручную это делать ну как то глупо Впрочем, других вариантов, кроме как переделать все вообще внутри, я пока не вижу. И этот вариант мне совсем не нравится

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

GS>Здравствуйте, Andrew S, Вы писали:

GS>>>Если тебе нужна поддержка COM, то я бы использовал ActiveScript. Собственно говоря, я другой просто не знаю.
Врапперы генерируются одновременно и для ActiveScript и для SpiderMonkey.

GS>ActiveScript очень удобен тем, что его можно дебагать на скриптовом уровне. Также можно переключиться, к примеру, c jscript на vbscript. Также влегкую реализовался внешний скриптинг и вообще управление приложением извне по COM интерфейсам.

GS>То есть получается (мета)программироваие на смеси XSLT/C++/JavaScript.
Плюс поддержка этого всего в WindowsCE, что немаловажно в силу разности в стоимости лицензий, — порядок

AS>Например, есть некий класс, в котором есть набор итемов std::vector<CItem *> или std::list<CItem>. Кроме того, на эти же итемы могут ссылаться внешние по отношению к этому объекты. Т.о. для актив скриптинга возникает проблема времени жизни объектов CItem. И сделать это все по-нормальному без переделки CItem на ком интерфейс будет очень непросто — ведь сейчас класс-контейнер контролирует время жизни экземпляра CItem, а для Com время жизни определяется счетчиком ссылок. Плюс возникает проблема эффективного создания подобных объектов. В случае list аллокатор может быть сколь угодно оптимизирован на создание мелких объектов, в отличие от стандартной фабрики интерфейсов, которую я вижу вариант сделать только по new.

Ну, не так всё и страшно на самом деле. Для того чтобы прицепить COM к такой системе делаешь врапперы следующим образом:
1. "Главный" обьект — в твоём случае обьект который имеет набор итемов std::vector<CItem *> — управляется через счётчик ссылок.
2. Для "подобьектов" — в твоём случае CItem — делаешь специальный класс, который имеет 2 итема — смартпоинтер на "Главный" обьект и индекс в массиве std::vector<CItem *> (как вариант — id обьекта). При каждом вызове функции получаешь указатель на CItem из "главного" обьекта по индексу.

Решение, конечно, не самое элегантное — но вполне рабочее. И не сказал бы что слишком сложное в имплементации.

AS>>Например, есть некий класс, в котором есть набор итемов std::vector<CItem *> или std::list<CItem>. Кроме того, на эти же итемы могут ссылаться внешние по отношению к этому объекты. Т.о. для актив скриптинга возникает проблема времени жизни объектов CItem. И сделать это все по-нормальному без переделки CItem на ком интерфейс будет очень непросто — ведь сейчас класс-контейнер контролирует время жизни экземпляра CItem, а для Com время жизни определяется счетчиком ссылок. Плюс возникает проблема эффективного создания подобных объектов. В случае list аллокатор может быть сколь угодно оптимизирован на создание мелких объектов, в отличие от стандартной фабрики интерфейсов, которую я вижу вариант сделать только по new.

L>Ну, не так всё и страшно на самом деле. Для того чтобы прицепить COM к такой системе делаешь врапперы следующим образом:
L>1. "Главный" обьект — в твоём случае обьект который имеет набор итемов std::vector<CItem *> — управляется через счётчик ссылок.
L>2. Для "подобьектов" — в твоём случае CItem — делаешь специальный класс, который имеет 2 итема — смартпоинтер на "Главный" обьект и индекс в массиве std::vector<CItem *> (как вариант — id обьекта). При каждом вызове функции получаешь указатель на CItem из "главного" обьекта по индексу.

L>Решение, конечно, не самое элегантное — но вполне рабочее. И не сказал бы что слишком сложное в имплементации.

В этом случае, как уже говорилось, проще запользовать смарт поинтер с семантикой владения (например, shared_ptr из буста). Объект будет жить, пока жив COM враппер. Другое дело, что почти наверняка удобнее и логичнее будет собственно сами объекты сделать COM. В этом случае они сами будут управлять временем жизни, а хранить в массиве можно те же CComPtr. Проблемы начинаются, когда объекты храняться в контейнере по значению. Например, list<CItem>. Вот тут уже менять придется кардинально все — и сам контейнер, и классы, которые его пользуют. В общем, это _очень_ большая проблема. Почему я и ищу варианты кроме актив скрипта.

AS>В этом случае, как уже говорилось, проще запользовать смарт поинтер с семантикой владения (например, shared_ptr из буста). Объект будет жить, пока жив COM враппер. Другое дело, что почти наверняка удобнее и логичнее будет собственно сами объекты сделать COM.

Решение которое я предлагал заточено на мимнимальные изменения уже существующего кода.

AS>В этом случае они сами будут управлять временем жизни, а хранить в массиве можно те же CComPtr. Проблемы начинаются, когда объекты храняться в контейнере по значению. Например, list<CItem>. Вот тут уже менять придется кардинально все — и сам контейнер, и классы, которые его пользуют.

Хм. Насколько я понимаю в этом случае решение которое я предлагаю тоже будет работать.

AS>В общем, это _очень_ большая проблема. Почему я и ищу варианты кроме актив скрипта.

AS>>В этом случае, как уже говорилось, проще запользовать смарт поинтер с семантикой владения (например, shared_ptr из буста). Объект будет жить, пока жив COM враппер. Другое дело, что почти наверняка удобнее и логичнее будет собственно сами объекты сделать COM.

L>Решение которое я предлагал заточено на мимнимальные изменения уже существующего кода.

AS>>В этом случае они сами будут управлять временем жизни, а хранить в массиве можно те же CComPtr. Проблемы начинаются, когда объекты храняться в контейнере по значению. Например, list<CItem>. Вот тут уже менять придется кардинально все — и сам контейнер, и классы, которые его пользуют.

L>Хм. Насколько я понимаю в этом случае решение которое я предлагаю тоже будет работать.

Каким образом? Например. есть list<CItem>. Объект в данном контейнере будет жить ровно столько, сколько захочет его хостер (в данном случае — list) и ни минутой больше. Никакие _внешние_ врапперы его не спасут — list не умеет передавать владение объектом другому списку, он неинтрузивен. А поскольку в Com объект сам убравляет временем жизни, то будет большой бабах с неплохой долей вероятности при попытке использования таких объектов из скрипта.

AS>Каким образом? Например. есть list<CItem>. Объект в данном контейнере будет жить ровно столько, сколько захочет его хостер (в данном случае — list) и ни минутой больше. Никакие _внешние_ врапперы его не спасут — list не умеет передавать владение объектом другому списку, он неинтрузивен.

Тогда переходим от хранения индекса к ID. И если CItem c таким ID уже удалён — тогда COM-враппер возвращает ошибку при попытке доступа к методам обьекта. И уже проблема скрипта разобраться с этим.

AS>А поскольку в Com объект сам убравляет временем жизни, то будет большой бабах с неплохой долей вероятности при попытке использования таких объектов из скрипта.

Ну не то что бы большой бабах Винт не отформатируется, просто скрипт упадёт.

Я кажется понял в чём проблема Если модель данных изначально планировалась с возможностью доступа из нескольких потоков то есть возможность получить данные так чтобы они были неизменны в какой-то конкретный момент времени. А если архитектура планировалась как однопоточная то пришить сюда скрипт (имеется в виду ActiveScript) будет тяжеловато именно потому что ему прийдётся работать из другого потока — а другой в это время будет менять данные как ему заблагорассудится. ИМХО основная проблема в этом, а не в согласовании проблем времени жизни.

AS>>Каким образом? Например. есть list<CItem>. Объект в данном контейнере будет жить ровно столько, сколько захочет его хостер (в данном случае — list) и ни минутой больше. Никакие _внешние_ врапперы его не спасут — list не умеет передавать владение объектом другому списку, он неинтрузивен.

L>Тогда переходим от хранения индекса к ID. И если CItem c таким ID уже удалён — тогда COM-враппер возвращает ошибку при попытке доступа к методам обьекта. И уже проблема скрипта разобраться с этим.

Боюсь, что за такое решение могут и покалечить Оторвать жизненно необходимые органы, или еще что... лучше так здоровьем не рисковать Вообще, конечно, интересно, как поступают обычно в таких случаях при написании DOM. Например, получаем 2 интерфейса одного итема (возможно, разными путями), удаляем один из итемов, и как себя после этого должен будет ощущать второй. Очевидно, что возможны варианты — он будет ощущать себя нормально, он будет ругаться "меня удалили, я не жив" либо все вообще упадет. Я полагаю, что должен быть реализован первый вариант — т.е. итема в коллекции уже не будет, но тем не менее он будет "жив".

Вообще, у меня стойкое ощущение, что экономически (и в плане кода, и в плане памяти) будет таки выгоднее сделать внутри все на Com. В этом случае мне не придется создавать и поддерживать 2 набора объектов, не надо будет создавать врапперы на каждый чих скрипта... В общем, ощущение, что таки придется (если решу делать на active script) переписывать все наново, ну, может получится таки саму логику не менять, это надо еще подумать.

AS>>А поскольку в Com объект сам убравляет временем жизни, то будет большой бабах с неплохой долей вероятности при попытке использования таких объектов из скрипта.

L>Ну не то что бы большой бабах Винт не отформатируется, просто скрипт упадёт.

L>Я кажется понял в чём проблема Если модель данных изначально планировалась с возможностью доступа из нескольких потоков то есть возможность получить данные так чтобы они были неизменны в какой-то конкретный момент времени. А если архитектура планировалась как однопоточная то пришить сюда скрипт (имеется в виду ActiveScript) будет тяжеловато именно потому что ему прийдётся работать из другого потока — а другой в это время будет менять данные как ему заблагорассудится. ИМХО основная проблема в этом, а не в согласовании проблем времени жизни.

Отнюдь. list<CItem> я могу сделать сколь угодно многопоточным банальным введением глобального лока на доступ\изменение объекта. И время жизни никоим образом на многопоточности не замешано — посмотрите ветку с попыткой реализации lock-free. Там как раз пытаются использовать семантику владения объектов для управления временим жизни и доступом и посмотрите, что из этого там получается

AS>Вообще, конечно, интересно, как поступают обычно в таких случаях при написании DOM. Например, получаем 2 интерфейса одного итема (возможно, разными путями), удаляем один из итемов, и как себя после этого должен будет ощущать второй. Очевидно, что возможны варианты — он будет ощущать себя нормально, он будет ругаться "меня удалили, я не жив" либо все вообще упадет. Я полагаю, что должен быть реализован первый вариант — т.е. итема в коллекции уже не будет, но тем не менее он будет "жив".

Натыкался на все 3 варианта в одном и том же вполне уважаемом продукте (MS Outlook)

AS>Вообще, у меня стойкое ощущение, что экономически (и в плане кода, и в плане памяти) будет таки выгоднее сделать внутри все на Com. В этом случае мне не придется создавать и поддерживать 2 набора объектов, не надо будет создавать врапперы на каждый чих скрипта... В общем, ощущение, что таки придется (если решу делать на active script) переписывать все наново, ну, может получится таки саму логику не менять, это надо еще подумать.

Затачивание всех обьектов под COM и его политики владения конечно же облегчит написание врапперов. Но если данные отдаются не в виде "снапшотов" а в виде набора динамически изменяющихся обьектов то есть у меня подозрение что всё равно это всех проблем не разрулит. Вот к примеру — элемент удалён из коллекции, но скрипт всё ещё держит ссылку на него. А у обьекта есть к примеру поле Master. Чему оно должно быть равно у удалённого обьекта? Старому значению или NULL? А если его не удалили а (что ещё хуже) переместили?

AS>Отнюдь. list<CItem> я могу сделать сколь угодно многопоточным банальным введением глобального лока на доступ\изменение объекта. И время жизни никоим образом на многопоточности не замешано — посмотрите ветку с попыткой реализации lock-free.

Если есть глобальный лок — то этот глобальный лок можно попробовать вынести в скрипт явно — как Quick-And-Dirty solution — пусть пользователь скрипта заботится о том чтобы вызвать lock а потом unlock. Если скрипт используется только для внутренних целей (в том плане что end-user на нём педалить не будет) — то вполне может проканать.

AS>Там как раз пытаются использовать семантику владения объектов для управления временим жизни и доступом и посмотрите, что из этого там получается

Ветку вроде бы видел — может не очень внимательно читал — куда смотреть-то?

AS>>Вообще, у меня стойкое ощущение, что экономически (и в плане кода, и в плане памяти) будет таки выгоднее сделать внутри все на Com. В этом случае мне не придется создавать и поддерживать 2 набора объектов, не надо будет создавать врапперы на каждый чих скрипта... В общем, ощущение, что таки придется (если решу делать на active script) переписывать все наново, ну, может получится таки саму логику не менять, это надо еще подумать.

L>Затачивание всех обьектов под COM и его политики владения конечно же облегчит написание врапперов. Но если данные отдаются не в виде "снапшотов" а в виде набора динамически изменяющихся обьектов то есть у меня подозрение что всё равно это всех проблем не разрулит. Вот к примеру — элемент удалён из коллекции, но скрипт всё ещё держит ссылку на него. А у обьекта есть к примеру поле Master. Чему оно должно быть равно у удалённого обьекта? Старому значению или NULL? А если его не удалили а (что ещё хуже) переместили?

Очевидно, новому значению. В случае удаления — NULL. В случае перемещения — новому владельцу. На мой взгляд, это как раз очевидно. Безусловно, возникают другие, менее очевидные вещи (например, появление итемов-долгожителей, зря коптящих небо), но это уже проблемы скрипта, в принципе.


AS>>Отнюдь. list<CItem> я могу сделать сколь угодно многопоточным банальным введением глобального лока на доступ\изменение объекта. И время жизни никоим образом на многопоточности не замешано — посмотрите ветку с попыткой реализации lock-free.

L>Если есть глобальный лок — то этот глобальный лок можно попробовать вынести в скрипт явно — как Quick-And-Dirty solution — пусть пользователь скрипта заботится о том чтобы вызвать lock а потом unlock. Если скрипт используется только для внутренних целей (в том плане что end-user на нём педалить не будет) — то вполне может проканать.

Многопоточности как раз нет. Если довольно сложные взаимосвязи между иерархией объектов. В принципе, если все корректно в скрипте описывать, то можно и без плясок со временем жизни. Но это путь к возможным багам — не хотелось бы. Слишком грязно. Тем более, что написание враппера, что переделка самих классов, как я теперь вижу, займет примерно одно время. Минус, конечно, что переносимость потеряется (сейчас там вполне все портабельно), но что делать...

AS>>Там как раз пытаются использовать семантику владения объектов для управления временим жизни и доступом и посмотрите, что из этого там получается

L>Ветку вроде бы видел — может не очень внимательно читал — куда смотреть-то?

http://www.rsdn.ru/Forum/Message.aspx?mid=1803031&amp;only=1

Автор: remark
Дата: 24.03.06

Это, собственно, итог

AS>Многопоточности как раз нет.

Многопоточность будет. IActiveScript::SetScriptState — блокирующая функция. Запускать её прийдётся в отдельном потоке — или полностью прописывать логику работы приложения уже на скрипте

L>>Ветку вроде бы видел — может не очень внимательно читал — куда смотреть-то?

AS>http://www.rsdn.ru/Forum/Message.aspx?mid=1803031&amp;only=1

Автор: remark
Дата: 24.03.06

AS>Это, собственно, итог

Спасибо

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

AS>Каким образом? Например. есть list<CItem>. Объект в данном контейнере будет жить ровно столько, сколько захочет его хостер (в данном случае — list) и ни минутой больше. Никакие _внешние_ врапперы его не спасут — list не умеет передавать владение объектом другому списку, он неинтрузивен. А поскольку в Com объект сам убравляет временем жизни, то будет большой бабах с неплохой долей вероятности при попытке использования таких объектов из скрипта.

Так сделай прозрачную обертку над CItem (например шаблонного вида).
В обертке будут несложные средства управления внешними COM объектами:
— Обертка создает каждый COM объект работы с CItem и сохраняет указатель на него во внутреннем списке.
— При удалении (изнутри деструктора обертки) вызываются внешние COM объекты и им сообщается об уничтожении объекта CItem. Далее они поступают как хотят: возвращают ли на запросы E_UNEXPECTED или же копируют данные объекта себе внутрь это уже их дело.

Можно даже сделать обратную связь от COM объектов на обертку, которая будет закладываться при конструировании COM объекта и отрываться при уведомлении об уничтожении объекта.

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

M>Здравствуйте, Andrew S, Вы писали:

AS>>Каким образом? Например. есть list<CItem>. Объект в данном контейнере будет жить ровно столько, сколько захочет его хостер (в данном случае — list) и ни минутой больше. Никакие _внешние_ врапперы его не спасут — list не умеет передавать владение объектом другому списку, он неинтрузивен. А поскольку в Com объект сам убравляет временем жизни, то будет большой бабах с неплохой долей вероятности при попытке использования таких объектов из скрипта.

M>Так сделай прозрачную обертку над CItem (например шаблонного вида).
M>В обертке будут несложные средства управления внешними COM объектами:
M>- Обертка создает каждый COM объект работы с CItem и сохраняет указатель на него во внутреннем списке.
M>- При удалении (изнутри деструктора обертки) вызываются внешние COM объекты и им сообщается об уничтожении объекта CItem. Далее они поступают как хотят: возвращают ли на запросы E_UNEXPECTED или же копируют данные объекта себе внутрь это уже их дело.

M>Можно даже сделать обратную связь от COM объектов на обертку, которая будет закладываться при конструировании COM объекта и отрываться при уведомлении об уничтожении объекта.

Да, в списке прийдется уже хранить обертки (каждая с CItem-ом внутри). Обертка, т.о. состоит из списка COM объектов и данных CItem.

И ещё. Если список требует операции копирования, то прийдется сделать ещё один уровень косвенности . При этом возникает объект — менеджер COM объектов, который будет заниматься тем, чем занималась обертка. Обертки, при этом, будут только передавать этого менеджера друг другу (тогда же, когда передаются данные CItem-а). Управление жизнью менеджера реализутся на смартах. Фактически в обертке остаются данные CItem и указатель на менеджера.

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

AS>>>Вообще, у меня стойкое ощущение, что экономически (и в плане кода, и в плане памяти) будет таки выгоднее сделать внутри все на Com. В этом случае мне не придется создавать и поддерживать 2 набора объектов, не надо будет создавать врапперы на каждый чих скрипта... В общем, ощущение, что таки придется (если решу делать на active script) переписывать все наново, ну, может получится таки саму логику не менять, это надо еще подумать.

мои пять копеек
за 3 года работы со скриптами (Lua5) не было ни одного дня когда я бы не порадовался что я не пользовался Com'ой и подобными тяжелыми решениями.
скрипты (~200k) пережили уже 8 major релизов. С++ часть — только 2.
Да здравствуют языки программирования в которых легко вносить изменения !
wbr

AS>>Многопоточности как раз нет.

L>Многопоточность будет. IActiveScript::SetScriptState — блокирующая функция. Запускать её прийдётся в отдельном потоке — или полностью прописывать логику работы приложения уже на скрипте

Именно это и нужно. Приложение представляет некоторые базовые сервисы (которые обязаны быть производительными), а остальное — собстственно всю логику работы приложения — определяет скрипт.
В связи с чем, кстати, вопрос. Как удобнее работать с гуем из скрипта? Пока мне надумался вариант создавать объект HTML-DOM, и уже в нем делать диалоги для общения с пользователем. Однако это... несколько муторно. Может, есть какие еще интересные варианты?

AS>>>>Вообще, у меня стойкое ощущение, что экономически (и в плане кода, и в плане памяти) будет таки выгоднее сделать внутри все на Com. В этом случае мне не придется создавать и поддерживать 2 набора объектов, не надо будет создавать врапперы на каждый чих скрипта... В общем, ощущение, что таки придется (если решу делать на active script) переписывать все наново, ну, может получится таки саму логику не менять, это надо еще подумать.

SD>мои пять копеек
SD>за 3 года работы со скриптами (Lua5) не было ни одного дня когда я бы не порадовался что я не пользовался Com'ой и подобными тяжелыми решениями.
SD>скрипты (~200k) пережили уже 8 major релизов. С++ часть — только 2.
SD>Да здравствуют языки программирования в которых легко вносить изменения !
SD>wbr

Дык я бы с удовольствием не пользовал active script. Поддерживал бы тот же Lua активх объекты...

AS>>Именно это и нужно. Приложение представляет некоторые базовые сервисы (которые обязаны быть производительными), а остальное — собстственно всю логику работы приложения — определяет скрипт.

L>Какое-то время назад это было прогрессивной идеей Но почему-то не прижилось, не знаю почему — не отслеживал историю вопроса .

Ну, для меня это, пожалуй, единственный возможный вариант — такова специфика разрабатываемой системы.

AS>>В связи с чем, кстати, вопрос. Как удобнее работать с гуем из скрипта? Пока мне надумался вариант создавать объект HTML-DOM, и уже в нем делать диалоги для общения с пользователем. Однако это... несколько муторно.

L>Делать интерфейс на HTML — вполне себе ничего решение, но имеет как свои плюсы так и свои минусы.

Ок, спасибо, примерно так я все себе и представляю. Посему, собственно, и главное требование к скрипту — поддержка активх.

язык С++

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

K>>Требования такие:
K>>1. Кроссплатформенность
K>>2. Работа с ECMAScript, но с возможностью расширения до синтаксиса близкого к C#
K>>3. Лёгкость интегрирования в существующий C++ проект
K>>4. Лёгкость самого scripting engine, то есть малый размер и скорость работы.

AS>Возник аналогичный вопрос. Требования (1 и 2) не нужно, кроме (3 и 4), нужна поддержка ActiveX\COM объектов а-ля VB или Java скрипт. Безусловно, можно сделать врапперы-интерфейсы для С++ объектов и сделать все на WSH, но как то это муторно, хотелось бы попроще. Может, какие из перечисленных или других скриптовых движков поддерживают ActiveX\COM? Кроме WSH, я других вариантов не нашел

Видел какой-то встраиваемый редактор, то ли Script IDE, то ли Macros IDE, точно не помню. Вроде чел с этого форума имеет к нему отношение. Попробуй прогуглить.