LINUX.ORG.RU

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

 , ,


1

3

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

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

daniilArch ★★
()
Ответ на: комментарий от zubapem

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

anonymous
()

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

dmitryshm
()
Ответ на: комментарий от zubapem

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

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

anonymous
()
Ответ на: комментарий от dmitryshm

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

zubapem
() автор топика
Ответ на: комментарий от zubapem

Глупая

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

anonymous
()
Ответ на: комментарий от anonymous

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

zubapem
() автор топика
Ответ на: комментарий от zubapem

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

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

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

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

anonymous
()

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

Vovka-Korovka ★★★★★
()
Ответ на: комментарий от anonymous

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

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

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

zubapem
() автор топика
Ответ на: комментарий от zubapem

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

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

anonymous
()
Ответ на: комментарий от zubapem

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

zubapem
() автор топика

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

anonymous
()

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

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

anonymous
()

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

anonymous
()
Ответ на: комментарий от zubapem

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

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

loz ★★★★★
()
Ответ на: комментарий от anonymous

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

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

dmitryshm
()
Ответ на: комментарий от zubapem

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

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

Stil ★★★★★
()

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

jtootf ★★★★★
()
Ответ на: комментарий от zubapem

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

nexfwall ★★★★
()
Ответ на: комментарий от nexfwall

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

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

zubapem
() автор топика
Ответ на: комментарий от zubapem

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

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

nexfwall ★★★★
()

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

В кого него?

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

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

sT331h0rs3 ★★★★★
()
Ответ на: комментарий от zubapem

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

ixrws ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.