Я знаю, что GC не был популярен в те дни, когда была разработана Ada, а для основного использования встроенного программирования это еще не очень хороший выбор.
Но учитывая, что Ada - это язык программирования общего назначения, который не был частичным и необязательным (трассирует только явно помеченные объекты памяти) сборщик мусора, представленный в последующих версиях языка и реализации компилятора.
Я просто не могу думать о разработке обычного настольного приложения без сборщика мусора.
Ада была разработана с учетом военных применений. Одним из главных приоритетов в его разработке был детерминизм. то есть хотелось, чтобы программа Ada последовательно выполняла точно так же каждый раз, в любой среде, во всех операционных системах... что-то вроде этого.
Сборщик мусора превращает одно приложение в два, работая друг против друга. Java-программы разрабатывают икоты в случайные интервалы, когда GC решает перейти на работу, и если это слишком медленно, есть вероятность, что приложение будет иногда выходить из кучи, а не другие.
Упрощенный: сборщик мусора вводит некоторую изменчивость в программу, которую дизайнеры не хотели. Вы делаете беспорядок - вы его очищаете! Тот же код, такое же поведение каждый раз.
Не то, чтобы Ада стала бушующим всемирным успехом, заметьте.
Поскольку Ada была разработана для использования в системах защиты, которые контролируют оружие в реальном времени, а сбор мусора влияет на время вашего приложения. Это опасно, поэтому на протяжении многих лет Java приходил с предупреждением о том, что он не должен использоваться для систем здравоохранения и военного контроля.
Я считаю, что причина, по которой больше не существует такого отказа от Java, заключается в том, что базовое оборудование стало намного быстрее, а также тот факт, что Java имеет лучшие алгоритмы GC и лучший контроль над GC.
Помните, что Ada была разработана в 1970 и 1980 годах в то время, когда компьютеры были гораздо менее мощными, чем сегодня, а в задачах управления приложениями были приоритетными.
ответ более сложный: Ada не требует сборщика мусора из-за ограничений в реальном времени и т.д. однако, язык был продуманным, чтобы позволить сборщик мусора.
хотя многие (почти все) компиляторы не включают сборщик мусора, есть заметная реализация:
есть много других источников информации о сборке мусора в Аде в Интернете. этот предмет подробно обсуждался, главным образом из-за ожесточенной конкуренции с Java в середине 90-х годов (см. эта страница: "Ada 95 is what the Java language should have been"), когда Java была "Следующая большая вещь", прежде чем Microsoft нарисовала С#.
Во-первых, на этом языке нет ничего, что запрещало сбор мусора.
Во-вторых, некоторые реализации выполняют сборку мусора. В частности, собираются все реализации, предназначенные для мусора JVM.
В-третьих, есть способ получить некоторое количество мусорной коллекции со всеми компиляторами. Видите ли, когда тип доступа выходит за пределы области видимости, если вы специально сказали языку выделить объем хранилища для хранения своих объектов, тогда это пространство будет уничтожено в этой точке. Я использовал это в прошлом, чтобы получить некоторые модификации сборки мусора. Объявление voodo, которое вы используете, это:
type Foo is access Blah;
for Foo'storage_size use 100_000_000; --// 100K
Если вы сделаете это, тогда вся (100K) памяти, выделенная объектам Blah, на которые указывают указатели Foo, будет очищена, когда тип Foo выходит за рамки. Поскольку Ada позволяет вам встраивать подпрограммы внутри других подпрограмм, это особенно эффективно.
Чтобы узнать больше о том, что могут сделать для хранения хранилища и хранилища, см. LRM 13.11
В-четвертых, хорошо написанные программы Ada не склонны полагаться на динамическое распределение памяти почти столько же, сколько программы C. C имел ряд конструктивных отверстий, которые практиканты научились использовать указатели для рисования. Многие из этих идиом не являются неотложными в Аде.
Во-первых, я хотел бы узнать, кто использует Аду в эти дни. Мне действительно нравится язык, и там даже есть библиотека GUI для Linux/Ada, но я ничего не слышал об активной разработке Ada в течение многих лет. Благодаря своим военным связям, я действительно не уверен, что это древняя история или так дико успешна, что все упоминания о ее использовании классифицируются.
Я думаю, что есть пара причин для отсутствия GC в Аде. Прежде всего, это относится к эпохе, когда большинство скомпилированных языков используют в основном стек или статическую память, или, в некоторых случаях, явное распределение кучи/бесплатно. GC как общая философия действительно снималась примерно в 1990 году, когда OOP, улучшенные алгоритмы управления памятью и процессоры, достаточно мощные, чтобы избавиться от циклов, чтобы запустить все это, пришли в свои руки. То, что Ада могла просто скомпоновать с мэйнфреймом IBM 4331 в 1989 году, просто беспощадно. Теперь у меня есть сотовый телефон, который может опередить процессор этой машины.
Еще одна веская причина заключается в том, что есть люди, которые считают, что строгий дизайн программы включает точный контроль над ресурсами памяти и что не должно быть никакого допуска, позволяющего плавать с динамически приобретенными объектами. К сожалению, слишком много людей закончили утечку памяти, поскольку динамическая память становилась все более и более правилом. Кроме того, как "эффективность" языка ассемблера на языках высокого уровня и "эффективность" исходных систем JDBC по сравнению с ORM, "эффективность" ручного управления памятью имеет тенденцию к инвертированию по мере ее масштабирования (я видел тесты ORM где эквивалент JDBC был только вдвое эффективнее). Контр-интуитивный, я знаю, но в наши дни системы намного лучше подходят для глобальной оптимизации больших приложений, плюс они в состоянии сделать радикальные повторные оптимизации в ответ на поверхностные незначительные изменения. Включая динамические алгоритмы повторной балансировки "на лету" на основе обнаруженных нагрузки.
Я боюсь, что мне придется отличаться тем, кто говорит, что системы реального времени не могут позволить себе память GC. GC уже не то, что замерзает всю систему каждые пару минут. У нас есть гораздо более разумные способы вернуть память в наши дни.
Я думал, что поделился бы очень простым примером того, как реализовать процедуру Free() (которая будет использоваться знакомым всем программистам на C)...
with Ada.Integer_Text_IO, Ada.Unchecked_Deallocation;
use Ada.Integer_Text_IO;
procedure Leak is
type Int_Ptr is access Integer;
procedure Free is new Ada.Unchecked_Deallocation (Integer, Int_Ptr);
Ptr : Int_Ptr := null;
begin
Ptr := new Integer'(123);
Free (Ptr);
end Leak;
Вызов Free в конце программы вернет выделенное Integer в пул хранения ( "куча" на языке C). Вы можете использовать valgrind, чтобы продемонстрировать, что это фактически предотвращает утечку 4 байтов памяти.
Ada.Unchecked_Deallocation (общая процедура) может использоваться (я думаю) любым типом, который может быть назначен с использованием ключевого слова "новое". Справочное руководство Ada ( "13.11.2 Unchecked Storage Deallocation" ) содержит более подробную информацию.
Ваш вопрос неверен. Оно делает. См. Пакет ada.finalization, который обрабатывает GC для вас.