Является ли основной реализацией* любого * популярного интерпретатора языка программирования, написанного на C++?



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



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



И, если нет, есть ли веская причина не писать интерпретатор на C++? Насколько я понимаю, код C++, если он написан правильно, может быть очень портативным и потенциально может компилироваться так же быстро, как и скомпилированный код C, который делает то же самое.

645   10  

10 ответов:

Я написал интерпретатор на C++ (после многих в C за эти годы), и я думаю, что C++ является достойным языком для этого. Что касается реализации, я бы только вернулся назад во времени и изменил свой выбор реализации возможности иметь несколько разных интерпретаторов, работающих одновременно (каждый многопоточный) просто потому, что это сделало код более сложным, и это то, что никогда не использовалось. Многопоточность весьма полезна, но несколько экземпляров интерпретатора были бессмысленный...

Однако теперь мое большое сожаление-это действительносам факт, что я написал этот интерпретатор , потому что теперь он используется в производстве с довольно большим количеством написанного кода и людей, обученных для него, и потому что язык довольно уродлив и менее силен, чем python... но переход на python теперь добавит затрат. В нем нет известных мне жучков... но все же это хуже, чем python, и это ошибка (в дополнение к ошибке, уже сделанной из оплаты стоимости написания его для no причина).

Я просто должен был изначально использовать python (или lua или любой другой готовый интерпретатор, который может быть легко встроен и который имеет разумное лицензирование)... мое единственное оправдание в том, что в то время я не знал ни о питоне, ни о Луа.

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

C++ все еще является языком низкого уровня, и хотя вы можете получить некоторую помощь, например, на стороне обработки памяти, все же основное предположение языка состоит в том, что ваш код на 100% прав, поскольку никакая ошибка во время выполнения не поможет вам (только неопределенные демоны поведения).

Если вы пропустили это предположение о 100% правильном коде для C (гораздо более простой язык), то я не вижу, как можете ли вы быть уверены, что напишете правильный код на C++ (монстр сложности по сравнению с ним)? Я подозреваю, что вы просто закончите с другим переводчиком багги, который вам придется выбросить.

Если вы написали текущую реализацию и-как вы говорите в своем комментарии-она имеет:

Неуклюжая обработка символов и многочисленные утечки памяти

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

Обновление: Я думаю, что комментарий sth правильно объясняет, почему многие языки реализуются на языке С, а не на языке с++. На тему полных переписок, прислушайтесь к словам Джоэла Спольски .

Да, многие из них. IIRC горячая точка Java VM написана на C++, Haskells ghc,...

Как многие здесь отметили, вы действительно должны взглянуть наLLVM , это инструментарий для построения компилятора, интерпретатора и виртуальных машин. Вы в основном выполняете работу frontend (то есть анализ вашего языка + семантический анализ + codegen в LLVM IR), и LLVM сразу же даст вам построение для разных платформ, jit, оптимизацию, компиляцию в машинный код,... Он также имеет некоторые инструменты для синтаксический анализ и AST, обработка ошибок и уведомления (но, возможно, это часть подпроекта Clang.)

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

И если вы начинаете новый проект для интерпретатора, написанного на C++ , он должен пройти долгий путь, чтобы стать основным реализация.

Движок Google Chrome V8 Javascript реализует ECMA-262, и это очень быстро. Может быть, вы могли бы переписать его в C++, но вы должны думать о других функциях, таких как реализация спецификации байт-кода вместо перезаписи ваших автоматов в C++. Перепишите его, это просто поможет организовать код (что является отличной вещью для групповой работы), но ничего в производительности.

Фонд GNU совсем недавно объявил, что все новые версии gcc будут написаны на языке c++.

Tamarin - интерпретатор Adobe и Mozilla ECMAScript написан на языке C++. Будучи тем, за который автор оригинального языка несет ответственность, он может считаться основным (IIRC эталонная реализация ECMA написана на OCaml, но фактически не используется, кроме как в качестве ссылки)

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

Вот учебник

Http://www.cprogramming.com/debugging/valgrind.html

Реализация Java Sun, по-видимому, написана в основном на C++.

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

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

Кроме того, большинство языков программирования имеют причину для существования, хотят решать проблемы по-другому (лучше обязательно означает по-другому, в конце концов), что означает, что у них есть довольно необычные потребности относительно того, что их код должен уметь делать, и не используют много средств поддержки, предлагаемых другим языком реализации, потому что у них не было бы достаточного контроля над ним. Таким образом, учитывая, что вы захотите повторно использовать много, например, объектную модель и типы данных, низкоуровневые аспекты C++ на самом деле являются преимуществом.

Тем не менее, многие языки начинаются с их первой версии, написанной на C++, первой простой например, компилятор, а затем написать следующую версию в этой простой версии ("bootstrapping"). Это имеет то преимущество, что вы можете использовать свой собственный язык, чтобы расширить его. Чтобы перенести его, они затем изменяют только свой компилятор для кросс-компиляции на нужную платформу, затем строят компилятор с этим кросс-компилятором, и в результате получается нативная версия полного языка для новой платформы.

Языки, которые, как правило, не делают этого, обычно в основном скриптовые языки, которые имеют тенденцию оставайтесь в интерпретации языков, реализованных на языке C++(хотя другие упоминали популярные исключения).

Еще одной распространенной причиной выбора C++ является существующая инфраструктура. Например, если вы хотите привязаться к существующим системным фреймворкам, вам часто нужно опускаться до C++, или если вы хотите воспользоваться преимуществами существующих бэкэндов компилятора (например, LLVM, который написан на C++), или даже если они используют только C, часто C++ является наиболее подходящим OO-подобным языком реализации, который может легко общаться с частями C в a система.

Поэтому вопрос, который вы хотите задать себе, скорее всего: Каковы мои потребности и какой язык лучше всего подходит для них?

Некоторые языки являются просто препроцессорами на другом языке (C++ и Objective-C оба начинали как препроцессоры на C). Они добавляют свой собственный синтаксис или функции, переводят их на язык реализации, а затем компилируют измененный код с помощью существующего компилятора. Если язык уже делает все, что вы хотите, это может быть лучшим подходом, и позволит вам используйте опыт инженеров, работающих над этим другим языком, объединяя свои рабочие часы в большее, чем вы сами могли бы обеспечить.

Comments

    Ничего не найдено.