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>Ветку вроде бы видел — может не очень внимательно читал — куда смотреть-то?
Многопоточность будет. IActiveScript::SetScriptState — блокирующая функция. Запускать её прийдётся в отдельном потоке — или полностью прописывать логику работы приложения уже на скрипте
L>>Ветку вроде бы видел — может не очень внимательно читал — куда смотреть-то?
AS>http://www.rsdn.ru/Forum/Message.aspx?mid=1803031&only=1
Здравствуйте, 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>Именно это и нужно. Приложение представляет некоторые базовые сервисы (которые обязаны быть производительными), а остальное — собстственно всю логику работы приложения — определяет скрипт.
Какое-то время назад это было прогрессивной идеей Но почему-то не прижилось, не знаю почему — не отслеживал историю вопроса .
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, с различиями между версиями и т.п.
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, точно не помню. Вроде чел с этого форума имеет к нему отношение. Попробуй прогуглить.
Винт не отформатируется, просто скрипт упадёт.
