четверг, 28 июля 2011 г.

embeddable languages

а вот например поскольку я совсем обленился устал уже писать мегабайты сорцов на C++, то искал давеча subj с целью встроить во всякие свои проекты
Критерии отбора не особо сложные - нужно чтобы:
  • работало на windows 32 & 64 бита
  • легко расширялось кодом на C/C++
  • не тащило с собой кучу runtime как например perl или python - т.е. нужно чтобы оно просто умело быть вкомпиленным внутрь многометрового .exe и никаких больше внешних файлов не требовало
  • более-менее строгую типизацию. Потому что например из скрипта придется общаться с собственным драйвером и потому оно может немножечко посинеть внезапно. По этой причине упячка под названием V8 JavaScript пролетает целиком и полностью
И вы таки мне не поверите, но оказалось что выбор весьма невелик:
  • lua
  • falcon
  • racket, хотя я не смотрел пока как у него с легкостью расширения
Удручает что многие кандидаты под windows de facto 32 bit only. Например ecl под linux поддерживает 64 бита, а под windows нет. Очень грустно

6 комментариев:

  1. Lua - рассово верная штука.

    Вообще в C++ на любой случай есть библиотеки, в связи с чем не совсем ясно, зачем вам embeddable languages (нужен скриптовый язык для собственного отладчика?). Посмотрите в сторону wxWidgets, там помимо GUI есть много всего полезного. Если нужны регулярные выражения - PCRE. Скачать из инета - cURLpp. Ну и тд.

    Кстати, от противного не пробовали - писать на чем-то высокоуровневом, что может расширяться с помощью C++, где это необходимо? Cython например или Haskell (да, функциональное программирование, trolling mode activated...).

    ОтветитьУдалить
  2. > Lua - рассово верная штука
    вывод сделан на основании собственного опыта или как обычно - "недавно в irc сказали" ?

    в исходном посте вроде бы ясно написано - мне нужен script engine, работающий целиком внутри моего же .exe и без всяких внешних зависимостей. Так что никаких "от противного", cython и haskell

    ОтветитьУдалить
  3. 1. Из опыта, из блогов, из вакансий на hh.ru.
    2. libperl статически линковать чем не вариант?

    ОтветитьУдалить
  4. тем что в нем все модули организованы строго как внешняя .dll и пачка .pm файлов во внешних директориях
    А мне нужно чтобы все было строго внутри

    Хотя конкретно perl я думаю можно было бы заточить под такую конфигурацию "все внутри", но тут будет проблема - а вдруг кто захочет заюзать в скрипте например Compress::Zlib или там Storable
    Проще взять более пригодный для встраивания язык и сказать ему - вот такие application specific модули у тебя есть и больше нету ничего и не будет

    ОтветитьУдалить
  5. Если уж решил юзать чего-то скриптового в качестве экстендера, то как быть с поинтерами ? Разве что их не юзать =) Но, например, в луа поинтеры костылём через таблицы делаются.

    ОтветитьУдалить
  6. я знаю минимум 1 встраиваемый язык, который умеет нормально работать с родными указателями. Только он давно мертв и порта под 64бита в природе не существует :-(

    ОтветитьУдалить