Встраиваемые языки

К примеру для того чтобы в будущем можно было писать аддоны к этой программе(на луа это будет приятнее чем на спп).

Как встраивание lua скажется на запуске основной программы и производительности в целом?

как GUI сказывается на c++ программе

Я использовал встраивание lua в игру на C++ для того, чтобы определить простой API на lua для дизайнеров игры, чтобы тем было легче осуществлять баланс игры. Этим был снижен порог входа дизайнера в работу над игрой.

Как встраивание lua скажется на запуске основной программы и производительности в целом?

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

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

Глупая

Идея встроенных языков в том, чтоб расширить существующий код, а DBus это RPC. Это разные вещи.

На языке lua любой может расширить функционал основной программы, выстроив в нужном порядке кирпичики-действия основной программы в нужной ему последовательности. Но мы эти кирпичики, тобишь api, пробрасываем через dbus, а значит пользователь взаимодействиует с основной программой через прослойку dbus (вызов функций) на его любимом языке программирования, а не на гвоздями прибитой прослойке lua.

А елсли головой подумать, а не задницей?

Вот есть у тебя игра и персонаж должен быть заскриптован. В случае с луа, ты просто идешь, и дергаешь описанные на луа функции из своего собсвенного процесса, получашь из скприта данные, персонаж работает, все просто.

В случае с DBus тебе нужно идти в другой процесс, который висит на каком-то канале, нужно учитывать то, что этот процесс может сдохнуть, канал может быть загружен, персонаж тормозит.

Это разные веши.

Кэп подсказывает, что есть программы, где встраиваемый язык нужен для выполнения только некоторой функциональности, а для основной функциональности уже есть куча готового кода на С/С++.

А елсли головой подумать, а не задницей?

Вот есть у тебя игра и персонаж должен быть заскриптован. В случае с луа, ты просто идешь, и дергаешь описанные на луа функции из своего собсвенного процесса, получашь из скприта данные, персонаж работает, все просто.

У тебя логика игры и управление персонажем разделено, т.е. lua использует «кодовые вставки» из основной программы, тогда в чем проблема перенести логику игры и функции управления персонажем в библиотеку и тогда можно дергать их уже из любого яп.. Тут и dbus рядом..

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

встроенный язык будет это состояние хранить сколько нужно, пока живет основной процесс, и может пользовать свои данные в любой момент времени. А процесс может отвалится и все потерять. Ну и еще, например, нужно 2 копии запустить. Будешь на каждую копию второй процесс-упраялтор создавать? или в одном разруливать? Это еще один слой геморроя, без которого можно обойтись.

функции управления персонажем в библиотеку

Ну так тоже делают. Но библиотеку написать еще надо, собрать и тд. А луа/питон это скрипт, который написал и готово к работе.

Ну так тоже делают. Но библиотеку написать еще надо, собрать и тд. А луа/питон это скрипт, который написал и готово к работе.

Функции вроде «прыжок», «влево» и т.п. перенести в библиотеку и вызывать их из любого другого яп.

Зачем перелогинился, шизофреник, когда тебя предыдущего еще не забанили?

Если писать с нуля можно и так как ты написал, но не во всех программах поддержка расширяемости была с первой версии.

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

Да, не понимаю, зачем в браузеры javascript встраивают? Ведь можно с каждой страничкой качать динамическую библиотеку под твою платформу, которая будет дергать через обычные вызовы функции браузера!

Но мы эти кирпичики, тобишь api, пробрасываем через dbus, а значит пользователь взаимодействиует с основной программой через прослойку dbus (вызов функций)

Ты так мутно описываешь обновление код на ходу?

В большей части не как.

Напишу немного не по теме. Но блин! Почему нам так надо переходить от приятной беседы по техническим моментам к какому-то выяснению отношений. Все то же самое можно говорить так, чтобы получать от общения удовольствие.

В сети часто нейтральный тон воспринимается как негативный. Не портите друг другу настроение!

У тебя логика игры и управление персонажем разделено, т.е. lua использует «кодовые вставки» из основной программы, тогда в чем проблема перенести логику игры и функции управления персонажем в библиотеку и тогда можно дергать их уже из любого яп.. Тут и dbus рядом..

Нука поясни. У тебя загрузился уровень Level_A с объектом Object_B, которого надо заскриптовать. С встраиваем языком ты просто запускаешь скрипт scripts/Level_A/Object_B.lua. А что ты будешь делать со своим DBus API?

Tcl используется обоими образами - встраиваясь в [rul=http://openocd.sourceforge.net/]OpenOCD и как расширение в Snack, например. дело вкуса

Можно. Но тогда процесс игры обязан быть одним(несколько копий не запустить). Этот язык будет ОБЯЗАН поддерживать DBUS. А еще DBUS будет тормозить, потому твои команды будут доходить с задержкой в 300 мс. И если процесс(интерпретатор ЯП), дёргающий за ниточки внезапно упадёт, кинув тебе в лицо ексепшн, некому будет их дёргать.

А еще DBUS будет тормозить, потому твои команды будут доходить с задержкой в 300 мс.

Почему такая высокая задержка? Мы же не поэмы будем слать, а действия - отправляем char-значение, он сам определяет что делать.

Потому что DBUS в userspace будет тормозить по определению. Не, ну можно конечно требовать какой-нибудь kdbus, только для того, чтобы поиграть в игрушку, но скорее тебя пошлют.

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

Вот у нас есть программа на C++, мы встроили в него питон.

В кого него?

Питон дергает программу на C++ для выполнения каких-нибудь действий, но почему нельзя поместить весь низкоуровневый код в библиотеку, слинковать ее с питоном и дергать библиотеку на выполнение производительных действий?

Питоновские модули можно писать на сях.

Идея хороша, а на практике будет очень плохо. Исключения тоже бывают(COM, XPCOM, там можно в рамках одного потока). В общем тут дело в том, что серьёзно компонетным строительством в масштабах индустрии никто не занимался. Есть только отдельные очаги начиная от multics с её разделяемыми либами-сегментами, заканчивая всякими WINRT. Всё равно, даже в венде разработчики недостаточно это используют, хотя вроде бы уже десятилетия работа с переменным успехом над этим там идёт.