Используете ли вы какие-либо интерпретаторы С++ (а не компиляторы)?

Мне интересно, если кто-то использовал UnderC, Cint, Cling, Ch или любой другой интерпретатор С++ и мог поделиться своим опытом.

Ответ 1

cint - это командный процессор для пакета анализа физики частиц ROOT. Я использую его регулярно, и он работает очень хорошо для меня.

Это довольно полно и хорошо сочетается с скомпилированным кодом (вы можете загружать скомпилированные модули для использования в интерпретаторе...)

поздний править:: Скопировано из более позднего дубликата, потому что плакат по этим вопросам, похоже, не хочет размещать здесь: igcc. Никогда не пробовал это лично, но веб-страница выглядит многообещающе.

Ответ 2

ПРИМЕЧАНИЕ. то, что следует, является скорее специфичным для CINT, но учитывая, что его, вероятно, самый широко используемый интерпретатор С++, он может быть действительным для них все.

Будучи аспирантом по физике частиц, который широко использовал CINT, я должен предупредить вас. Хотя он "работает", он находится в процессе постепенного отказа, а те, кто проводит больше года в физике частиц, обычно учатся избегать его для нескольких причины:

Из-за своих корней как интерпретатора C он не может интерпретировать некоторые из наиболее важных компонентов С++. Шаблоны, например, не всегда работают, поэтому вам не рекомендуется использовать вещи, которые делают С++ настолько гибкими и пригодными для использования.
Он медленнее (по крайней мере в 5 раз), чем минимально оптимизированный С++.
Отладочные сообщения гораздо более загадочны, чем сообщения g++.
Скопирование несовместимо с скомпилированным С++: довольно распространено видеть код формы
```
if (energy > 30) { 
    float correction = 2.4;
}
else {
    float correction = 6.3;
}

somevalue += correction; 
```
тогда как любой рабочий компилятор С++ будет жаловаться на то, что correcton вышел из сферы действия, CINT позволяет это. В результате CINT-код на самом деле не С++, просто что-то похожее на него.

Короче говоря, CINT не имеет ни одного преимущества С++, и все недостатки плюс некоторые.

Тот факт, что CINT все еще используется, скорее всего, является скорее исторической катастрофой из-за ее включения в структуру ROOT. Когда он был написан (20 лет назад), появилась настоятельная потребность в интерпретируемом языке для интерактивного построения/подгонки. Теперь есть много пакетов, которые заполняют эту роль, многие из которых имеют сотни активных разработчиков.

Ни один из них не написан на С++. Зачем? Проще говоря, С++ не предназначен для интерпретации. Например, статическая типизация покупает вам большую выгоду в оптимизации во время компиляции, но в основном служит для загромождения и чрезмерного ограничения вашего кода, если компьютеру разрешено видеть его во время выполнения. Если у вас есть возможность использовать интерпретируемый язык, изучите Python или Ruby, время, затрачиваемое вами на обучение, будет меньше, чем вы теряете спотыкание над CINT, даже если вы уже знаете С++.

По моему опыту, более старые исследователи, которые работают с ROOT (пакет, который вы должны установить для запуска CINT), в конечном итоге компилируют библиотеки ROOT в обычные исполняемые файлы С++, чтобы избежать CINT. Те, кто в младшем поколении, либо следуют этому примеру, либо используют Python для написания сценариев.

Кстати, ROOT (и, таким образом, CINT) занимает примерно полчаса, чтобы скомпилировать его на довольно современном компьютере и иногда будет терпеть неудачу с более новыми версиями gcc. Это пакет, который служил важной цели много лет назад, но теперь он ясно показывает возраст. Изучая исходный код, вы найдете сотни устаревших отливок c-стиля, огромные дыры в типе безопасности и интенсивное использование глобальных переменных.

Если вы собираетесь писать С++, напишите С++, поскольку это должно быть написано. Если у вас обязательно должен быть С++-интерпретатор, CINT, вероятно, хорошая ставка.

Ответ 3

Существует cling Cern project интерпретатора С++ на основе clang - это новый подход, основанный на 20-летнем опыте работы с ROOT cint и довольно стабильным и рекомендованным парнем Cern.

Вот хороший Google Talk: Представляем cling, С++ Interpreter на основе clang/LLVM.

Ответ 4

У меня (около года назад) играл с Ch и нашел, что это очень хорошо.

Ответ 5

Давным-давно, я использовал интерпретатор С++, называемый CodeCenter. Это было довольно хорошо, хотя он не мог справиться с такими вещами, как бит-поля или причудливое манипулирование указателями. Эти две интересные вещи касались того, что вы могли наблюдать, как изменяются переменные, и что вы можете оценивать код C/С++ на лету во время отладки. В эти дни, я думаю, отладчик, такой как GDB, в основном так же хорош.

Ответ 6

Также давно я использовал вызов продукта Instant C, но я не знаю, что он когда-либо развивался

Ответ 7

Я снова посмотрел, как использовать ch, чтобы посмотреть, могу ли я использовать его для библиотек DLL с черным ящиком, за которые я несу ответственность. К сожалению, я не мог понять, как заставить его загружать и выполнять функции из DLL. Опять же, я не был таким мотивированным, и вполне может быть способ.

Ответ 8

Существует программа под названием c-repl, которая работает путем многократной компиляции вашего кода в разделяемые библиотеки с использованием GCC, а затем для загрузки результирующих объектов. Кажется, он быстро развивается, учитывая версия в репозитории Ubuntu написана в Ruby (не считая GCC, конечно), а последняя git находится в Haskell.:)