it-swarm-ru.tech

Вы использовали какой-либо из интерпретаторов C++ (не компиляторы)?

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

65
Allan Wind

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

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

  1. Из-за своих корней как интерпретатора C, он не может интерпретировать некоторые из наиболее важных компонентов C++. Например, шаблоны не всегда работают, поэтому вам не рекомендуется использовать вещи, которые делают C++ настолько гибким и удобным. 

  2. Это медленнее (по крайней мере, в 5 раз), чем минимально оптимизированный C++. 

  3. Сообщения отладки гораздо более загадочны, чем сообщения, создаваемые g ++. 

  4. Область видимости несовместима с откомпилированным C++: довольно часто можно увидеть код вида 

    if (energy > 30) { 
        float correction = 2.4;
    }
    else {
        float correction = 6.3;
    }
    
    somevalue += correction; 
    

    тогда как любой работающий компилятор C++ будет жаловаться, что correcton вышел из области видимости, CINT позволяет это. В результате код CINT на самом деле не является C++, а выглядит так. 

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

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

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

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

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

Если вы собираетесь писать на C++, пишите на C++ так, как это должно быть написано. Если вам абсолютно необходимо иметь интерпретатор C++, CINT, вероятно, хорошая ставка. 

29
Shep

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

Вот что приятно Google Talk: Представляем cling, интерпретатор C++ на основе clang/LLVM .

23
Grzegorz Wierzowiecki

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

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

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

19
dmckee

Я (около года назад) поиграл с Ch и нашел, что это довольно хорошо.

4
Alan

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

2
jfm3

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

2
user11269

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

0
Matthew Flaschen

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

0
Jon Trauntvein