Если не использовать сборку "мусора"?

Временное безумие?

На самом деле единственный случай, я знаю этого, что Вы не покрыли, является так называемым "основанным на времени жизни управлением памятью", которое иногда идет под именем "пулы" или "арены" или "регионы". Идея состоит в том, что Вы собираетесь выделить тонну объектов, вероятно, маленьких, и они все собираются умереть сразу. Таким образом, у Вас есть дешевое средство выделения, и затем Вы восстанавливаете все объекты в единственной бесплатной операции.

В эти дни существуют исследования программы, которые позволят компилятору сделать это для Вас, но если Вы пишете код C, Вы делаете это вручную. Существует реализация с примерами в Интерфейсах C Dave Hanson и Реализации, и она используется на Фрейзере и Hanson lcc компилятор, который записан в C без сборщика "мусора".

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

При программировании для встроенных устройств с ограниченными ресурсами. iPhone, например, использует подсчет ссылок.

Или при программировании чего-то, что чрезвычайно интенсивно на компьютере. SETI@Home и видеоигры приходят на ум.

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

Emm... причина моего преподавателя должна сделать наш (его студенты) жизнью тяжелее и преподавать нам "реальную вещь". Ха-ха :)

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

Единственная причина НЕ использовать Сборку "мусора" для управления ресурсами состоит в том, если Вы хотите использовать крыло RAII C++, но поскольку это применяется просто к памяти, даже затем это - разумная идея использовать его. (Отметьте: все еще возможно сделать так, с глюком имел отношение к недетерминированному завершению).

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

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

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

Как насчет из соображений безопасности? Например, если бы у Вас есть закрытый ключ шифрования в памяти, Вы, вероятно, хотели бы ее вокруг в течение самого короткого времени.

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

При создании высокоэффективных приложений, таких как игры шутера от первого лица Вы не хотите GC, который потенциально повлияет на выполнение Вашего приложения. Вручную управление памятями в тех приложениях позволяет Вам решать правильное время к свободному ресурсы.