Основной минус такого "встраивания" - в самой софтине межкомпонентный код становится платформозависимым. Просто нужен вменяемый компонентный фреймворк. Универсального решения нет, достаточно посмотреть на проблемы BlackBox. Кое-что по этой проблеме давно уже обсуждали - п.5
http://caxapa.ru/132624.html
Основной минус такого решения - затруднённая сборка мусора(из-за работы с указателями). Однако есть механизмы, позволяющие обойтись без неё -
http://caxapa.ru/u …30090/eth-30090-02.pdf
цитата: "Идея в том, что компонентные переменные ссылочные, но их значения нельзя присваивать друг другу как это обычно делается с указателями. Значения переменных можно либо перемещать (MOVE), тогда старая переменная становится "пустой", или же можно делать копию. Таким образом получается, что у любого компонента всегда есть только один владелец. Поэтому сборщик мусора становится не нужен: удаление агрегата = удаление всех его компонентов. А динамические структуры (графы связей) делаются через ассоциативные индексы."
Т.е. компонентный фреймворк должен обеспечить работу со ссылками и сериализацию. Это минимальные требования. Тогда можно избавиться от native API между компонентами.
Д.ARMоед (25.02.2012 11:02, просмотров: 994) ответил Evgeny_CD на Вообще это свойство нормальной ОСи - запустить процесс из процесса. И чего-нибудь получить от него через IPC. И ее API. И если язык (и либы) поддерживают это API - то они адекватны. Нет - не подходят для такой задачи. В общем, все нормальные языки