Интерпретируемые языки с ручным управлением памятью?

В некоторых высокопроизводительных интерпретанных языках, таких как lua , вы можете вручную обращаться с сборкой мусора. Смотреть lua_gc .

Какой интерпретированные языки имеют ручное управление памятью? Я не вспоминаю, как когда-либо слушал один.

Нет такой вещи, как интерпретировать язык . Язык не скомпилирован, ни интерпретируется. Язык всего . Язык - это куча абстрактных математических правил. Интерпретация или компиляция являются признаками осуществления языка , у них нет ничего , чтобы сделать с языком. Каждый язык может быть реализован либо компилятором, либо переводчиком; Большинство современных высокопроизводительных языковых реализаций фактически используются , так и между ними , так и переключатель между ними в зависимости от того, какой из них будет быстрее в определенном контексте.

C скомпилированный язык? Там есть переводчики. Питона интерпретированным языком? Все 8 текущих реализаций Python используют компилятор.

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

Другим примером будет самая первая версия Lisp с 1958 года: она имела ручное управление памятью (на основе отсчета ссылок), но она была заменена только пару месяцев спустя Версия с автоматическим управлением памятью, которое она использовала с тех пор. Хотя опять же, любой язык может быть реализован с компилятором, либо интерпретатором, поэтому я не знаю, имел ли эту версию интерпретировать реализацию или скомпилированную. (На самом деле, я не уверен, был ли он реализован вообще .)

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

Так что отвечая на эту часть вопроса:

не является серьезной проблемой о Интерпретаторы языки не детерминированные задержки (или пространство сложность, когда там недостаточно задержка) сборки мусора? Так почему не просто писать что-то в точности Java, но заставляет вас свободно память вручную?

Это может быть забота о некоторых системах. Не столько проблема для других систем. Программное обеспечение, работающее с сборкой мусора, может выделить память быстрее, чем системы, которые просто называют malloc. Конечно, вы в конечном итоге выплачиваете время позже в GC Time.

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

Есть много разных стратегий для сборки мусора. Какая стратегия лучше всего для системы будет зависеть от требований. Но даже если вам требуется абсолютный детерминизм, вы можете использовать что-то вроде: Realtime Java

Есть некоторые интерпретаторы C / C ++, доступные, например, этот .

Не пробовала его самостоятельно, но я думаю, что поскольку он утверждает, что он будет совместимым для скомпилированного C / C ++, ему необходимо иметь «ручное» управление памятью.

Причина - циклические ссылки, исключения нулевых указателей и несколько ссылок. Простой пример:

var a = new Object();
var b = a;
a = null;//or delete a or free a or whatever;
print(b);//what now? is b null? or is b still new Object()?

Если в приведенном выше примере значение b теперь равно null, при переопределении переменных возникают некоторые серьезные проблемы. Например, что делать, если вместо настройки a установить значение c ? b также c ?

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

Далее укладывают области памяти, которые могут быть выпущены с забыванием.

Не следует вызывать Thread.run, вызвать Thread.start

public void run ()

Если этот поток был создан с использованием отдельного Runnable run object, затем этот Runnable вызывается метод выполнения объекта; в противном случае этот метод ничего не делает и возвращает.

Очевидно, следует использовать nvarchar (max) :

MSDN

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

API Python API, позволяет включить или выключить задержку сбора мусора - Проверьте документацию на модуле «GC» стандартной библиотеки:

http://docs.cython.org/library/gc.html

Но это не то, что делает его медленно, по сравнению со статическими языками - Динамическая природа сама данных - это сеть, отвечающая за различия в скорости.

Предпосылки, стоящие за вопросом, несколько сомнительны:

• Модель памяти является свойством языка , а не его выполнение.

• Интерпретация - это свойство реализации , а не языка.

Примеры:

• Язык программирования Scheme имеет автоматическое управление памятью и множество десятков интерпретируемых реализаций, а также несколько прекрасных компиляторов машинного кода, включая Larceny, Gambit и PLT Scheme (который включает оба интерпретатор и JIT-компилятор, выполняющие плавные переходы).

• В языке программирования Haskell есть автоматическое управление памятью; две самые известные реализации - это интерпретатор HUGS и компилятор GHC . Есть несколько других достойных реализаций, поровну разделенных между компиляцией в машинный код (yhc) и интерпретацией (Helium).

• В языке программирования C есть ручное управление памятью, и, хотя мир полон компиляторов C, те из нас, кто достаточно взрослый, чтобы помнить славные 1980-е, могут помнить Sabre-C или C-terp, два очень полезных интерпретатора C для MS- ДОС.

Тем не менее, за вашим вопросом стоит правдивое наблюдение: языки с ручным управлением памятью обычно компилируются . Почему?

• Ручное управление памятью - это устаревшая функция, которая часто используется для обеспечения совместимости с устаревшим кодом. Унаследованные языки обычно достаточно зрелы, чтобы иметь компиляторы нативного кода.

• Многие новые языки определяются реализацией. Собрать интерпретатор проще, чем компилятор.Проще реализовать простое автоматическое управление памятью в интерпретаторе, чем реализовать высокопроизводительное автоматическое управление памятью в компиляторе машинного кода. Итак, если язык получает свое определение из своей первой реализации, автоматическое управление памятью коррелирует с интерпретацией, потому что в интерпретируемой настройке реализация проще.

• Ручное управление памятью также (и иногда даже оправданно) используется для повышения производительности. Превосходные экспериментальные исследования Бена Зорна, проведенные в 1990-х годах, показывают, что автоматическое управление памятью работает так же быстро или быстрее, чем ручное управление памятью, но требует примерно вдвое больше памяти. Поэтому ручное управление памятью часто используется на очень маленьких устройствах, где памяти не хватает, и в очень больших центрах обработки данных, где удвоение памяти обходится дорого. (Его также иногда используют люди, мало разбирающиеся в управлении памятью, но слышавшие, что сборка мусора происходит медленно. Они были правы в 1980 году.) чем переводчик.

  Некоторые из действительно интересных исключений также происходят из этого принципа. Например, и FORTH, и самые первые реализации PostScript были разработаны для работы на небольших встроенных устройствах (телескопах и принтерах), где ресурсов памяти было мало, но время вычислений не имело значения. Оба языка были впервые реализованы с использованием байт-кодов, которые были более компактными, чем собственный код, и оба имели возможность ручного управления памятью. Итак: переводчики с ручным управлением памятью.(В более поздних версиях PostScript добавлена ​​опция для сборки мусора.)

В итоге:

• Автоматическое и ручное управление памятью - это язык .

• Скомпилированная и интерпретированная реализация .

• В принципе два выбора могут быть и сделаны ортогонально , но по прагматическим техническим причинам автоматическое управление памятью часто коррелирует с интерпретацией .

Разве основная проблема интерпретируемых языков не в недетерминированных задержках (или пространственной сложности, когда задержек недостаточно) сборки мусора?

Я не знал, что там было серьезную озабоченность по поводу интерпретируемых реализаций языков программирования. В алфавитном порядке Lua, Perl, PostScript, Python и Ruby являются чрезвычайно успешными, а Icon, Scheme и Squeak Smalltalk - умеренно успешными. Единственная область, в которой непредсказуемые задержки вызывают беспокойство, - это вычисления в реальном времени, такие как система ABS, которая управляет тормозами вашего автомобиля (если вы управляете достаточно модным автомобилем).

Примечание добавлено после редактирования вопроса: Вы изменили "интерпретируемый" на "без указателя". Но в комментарии вы говорите, что хотите спросить о языках с помощью new и delete . Любой язык с new и delete имеет указатели: по определению, все, что возвращает new , является указателем. (В некоторых языках могут быть и другие источники указателей.Итак, я думаю, что вы имеете в виду «языки без арифметики указателей и без оператора адресации».