Почему в C ++ нет сборщика мусора?

Я не задаю этот вопрос из-за достоинств сборки мусора в первую очередь. Моя главная причина, по которой я спрашиваю об этом, состоит в том, что я знаю, что Бьярн Страуструп сказал, что C ++ будет иметь сборщик мусора в определенный момент времени.

С учетом сказанного, почему он не был добавлен? Уже есть несколько сборщиков мусора для C ++. Это просто одна из тех вещей, которые легче сказать, чем сделать? Или есть другие причины, по которым он не был добавлен (и не будет добавлен в C ++ 11)?

Перекрестные ссылки:

• Сборщики мусора для C ++

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

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

Цитата самого Бьярна Страуструпа:

Я надеялся, что сборщик мусора, который может быть включен по выбору, будет частью C ++ 0x, но у меня было достаточно технических проблем, которые я должен был решить, просто подробно описав, как такой сборщик интегрируется с остальным языком. , если предусмотрено. Как и в случае практически всех функций C ++ 0x, существует экспериментальная реализация.

Существует хорошее обсуждение этой темы здесь .

Общий обзор:

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

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

Есть 2 типа сборки мусора ...

Явная сборка мусора:

C ++ 0x будет иметь сборку мусора через указатели, созданные с помощью shared_ptr

Если вы хотите, вы можете использовать его, если вы не хотите, вы не обязаны использовать его.

В настоящее время вы можете использовать boost: shared_ptr, если вы не хотите ждать C ++ 0x.

Неявная сборка мусора:

У этого нет прозрачной сборки мусора все же. Это будет основной темой для будущих спецификаций C ++.

Почему Tr1 не имеет неявной сборки мусора?

Бьярн Страуструп (Bjarne Stroustrup) в предыдущих интервью сказал, что есть много вещей, которые должен был иметь tr1 в C ++ 0x.

Чтобы добавить к дискуссии здесь.

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

1. Производительность?

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

В настоящее время широко распространены 2 семейства GC:

• Марка-и-Sweep вид
• Подсчет ссылок

Это Mark And Sweepбыстрее (меньше влияет на общую производительность), но страдает от синдрома «заморозить мир»: то есть, когда включается GC, все остальное останавливается, пока GC не выполнит очистку. Если вы хотите построить сервер, который отвечает за несколько миллисекунд ... некоторые транзакции не будут соответствовать вашим ожиданиям :)

Проблема в Reference Countingдругом: подсчет ссылок увеличивает издержки, особенно в многопоточных средах, потому что вам нужен атомный счет. Кроме того, существует проблема референтных циклов, поэтому вам нужен умный алгоритм для обнаружения этих циклов и их устранения (обычно реализуется также «заморозить мир», хотя и реже). В целом, на сегодняшний день этот тип (хотя обычно более отзывчивый или, скорее, замерзает реже) медленнее, чем Mark And Sweep.

Я видел статью разработчиков Eiffel, которые пытались реализовать Reference Countingсборщик мусора, который имел бы аналогичную глобальную производительность Mark And Sweepбез аспекта «Freeze The World». Требуется отдельная тема для GC (типовая). Алгоритм был немного пугающим (в конце), но статья хорошо поработала, представляя концепции по одному и показывая эволюцию алгоритма от «простой» версии к полноценной. Рекомендуем прочитать, если только я смогу вернуть руки к PDF-файлу ...

2. Приобретение ресурсов - это инициализация (RAII)

Это распространенная идиома, заключающаяся в C++том, что вы будете связывать владение ресурсами внутри объекта, чтобы обеспечить их правильное освобождение. Он в основном используется для памяти, поскольку у нас нет сборки мусора, но, тем не менее, он полезен и для многих других ситуаций:

• блокировки (многопоточность, дескриптор файла, ...)
• соединения (с базой данных, другим сервером, ...)

Идея состоит в том, чтобы должным образом контролировать время жизни объекта:

• он должен быть живым столько, сколько вам нужно
• это должно быть убито, когда вы закончите с этим

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

У языков с GC есть два обходных пути:

• не используйте GC, когда выделение стека достаточно: обычно это связано с проблемами производительности, но в нашем случае это действительно помогает, поскольку область действия определяет время жизни
• usingпостроить ... но это явный (слабый) RAII, в то время как в C ++ RAII является неявным, так что пользователь НЕ МОЖЕТ невольно сделать ошибку (опуская usingключевое слово)

3. Умные указатели

Умные указатели часто выглядят как серебряная пуля для обработки памяти C++. Часто я слышал: нам не нужен GC, потому что у нас есть умные указатели.

Нельзя быть более неправильным.

Умные указатели действительно помогают: auto_ptrи unique_ptrиспользуют концепции RAII, что чрезвычайно полезно. Они настолько просты, что вы можете написать их самостоятельно довольно легко.

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

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

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

4. Какое решение?

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

• предпочитаю иметь одного владельца в одно время, если это возможно
• если нет, убедитесь, что на вашей диаграмме классов нет циклов, относящихся к владению, и разбейте их с тонким применением weak_ptr

Так что, действительно, было бы здорово иметь GC ... однако это не тривиальная проблема. А пока нам просто нужно закатать рукава.

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

C / c ++ используется в самых разных обстоятельствах. Я подозреваю, что что-то вроде повышения умных указателей будет достаточно для большинства пользователей

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

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

• детерминированные времена жизни объектов (подсчет ссылок дает вам это, но GC нет. Хотя это может быть не так уж важно).
• что произойдет, если деструктор сгенерирует объект при сборке мусора? Большинство языков игнорируют это исключение, поскольку на самом деле нет блока catch, чтобы можно было его транспортировать, но это, вероятно, не является приемлемым решением для C ++.
• Как включить / отключить это? Естественно, это, вероятно, будет решение во время компиляции, но код, написанный для GC, против кода, который написан для NOT GC, будет сильно отличаться и, вероятно, несовместим. Как вы примиряете это?

Это лишь некоторые из проблем, с которыми сталкиваются.

Хотя это старый вопрос, есть еще одна проблема, о которой я не вижу, чтобы кто-то вообще обращался к ней: сборка мусора практически невозможно определить.

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

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

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

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

Тем не менее, это сильнее, чем было предложено для C ++. Предыдущее предложение [предупреждение: PDF] (что были понижены) не гарантия вообще ничего. На 28 страницах предложения вы заметили внешне наблюдаемое поведение в виде одной (ненормативной) записки, в которой говорилось:

[Примечание: для программ, собираемых мусором, высококачественная размещенная реализация должна пытаться максимизировать объем недоступной памяти, которую она восстанавливает. —Конечная записка]

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

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

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

Если вы хотите автоматическую сборку мусора, есть хорошие коммерческие и общедоступные сборщики мусора для C ++. Для приложений, для которых подходит сборщик мусора, C ++ является отличным языком сборки мусора, производительность которого выгодно отличается от других языков сборки мусора. См. Язык программирования C ++ (4-е издание) для обсуждения автоматической сборки мусора в C ++. Смотрите также, Ганс-Дж. Сайт Бема для сборки мусора на C и C ++ ( архив ).

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

Источник: http://www.stroustrup.com/bs_faq.html#garbage-collection

Что касается того, почему он не имеет встроенного, если я правильно помню, что он был изобретен до того, как GC был предметом , и я не верю, что язык мог иметь GC по нескольким причинам (совместимость IE с обратной связью с C)

Надеюсь это поможет.

Страуструп сделал несколько хороших комментариев по этому поводу на конференции Going Native 2013 года.

Просто перейдите к 25м50 в этом видео . (Я бы порекомендовал посмотреть все видео на самом деле, но это пропускает материал о сборке мусора.)

Если у вас действительно отличный язык, который позволяет легко (и безопасно, и предсказуемо, и легко читаться, и легко учить) работать с объектами и значениями прямым способом, избегая (явного) использования куча, тогда вам даже не нужна сборка мусора.

С современным C ++ и тем, что есть в C ++ 11, сборка мусора больше не нужна, за исключением ограниченных обстоятельств. Фактически, даже если хороший сборщик мусора встроен в один из основных компиляторов C ++, я думаю, что он не будет использоваться очень часто. Будет проще , а не сложнее избежать ГК.

Он показывает этот пример:

void f(int n, int x) {
    Gadget *p = new Gadget{n};
    if(x<100) throw SomeException{};
    if(x<200) return;
    delete p;
}

Это небезопасно в C ++. Но это также небезопасно в Java! В C ++, если функция возвращается рано, deleteникогда не будет вызываться. Но если у вас была полная сборка мусора, такая как в Java, вы просто получаете предположение, что объект будет уничтожен «в какой-то момент в будущем» ( Обновление: это еще хуже, чем это. Java делает НеОбещаю называть финализатор когда-либо - возможно, он никогда не будет вызван). Этого недостаточно, если гаджет содержит дескриптор открытого файла, или соединение с базой данных, или данные, которые вы буферизировали для записи в базу данных на более позднем этапе. Мы хотим, чтобы гаджет был уничтожен, как только он будет завершен, чтобы освободить эти ресурсы как можно скорее. Вы не хотите, чтобы ваш сервер баз данных боролся с тысячами соединений с базами данных, которые больше не нужны - он не знает, что ваша программа закончила работать.

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

void f(int n, int x) {
    Gadget p = {n};  // Just leave it on the stack (where it belongs!)
    if(x<100) throw SomeException{};
    if(x<200) return;
}

Для этого требуется меньше символов. Это не newмешает. Это не требует, чтобы вы печатали Gadgetдважды. Объект уничтожается в конце функции. Если это то, что вы хотите, это очень интуитивно понятно. Gadgets ведут себя так же, как intили double. Предсказуемый, легкий для чтения, легкий в обучении. Все это «ценность». Иногда это большая ценность, но ценности легче учить, потому что у вас нет такого «действия на расстоянии», которое вы получаете с помощью указателей (или ссылок).

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

Область и срок службы важны. В большинстве случаев проще, если время жизни совпадает с областью действия. Это легче понять и легче учить. Когда вам нужно другое время жизни, должно быть очевидно, что вы читаете код, который делаете, shared_ptrнапример. (Или возвращая (большие) объекты по значению, используя семантику перемещения или unique_ptr.

Это может показаться проблемой эффективности. Что делать, если я хочу вернуть гаджет foo()? Семантика перемещения C ++ 11 облегчает возвращение больших объектов. Просто напишите, Gadget foo() { ... }и это будет просто работать, и работать быстро. Вам не нужно связываться с &&самим собой, просто возвращайте вещи по значению, и язык часто сможет выполнить необходимые оптимизации. (Еще до C ++ 03 компиляторы проделали замечательную работу, избегая ненужного копирования.)

Как сказал Страуструп в другом месте на видео (перефразируя): «Только компьютерный специалист будет настаивать на копировании объекта, а затем уничтожении оригинала. (Аудитория смеется). Почему бы просто не переместить объект непосредственно в новое место? Это то, что люди (не компьютерные ученые) ожидать. "

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

Если это не работает для вас, вы можете использовать unique_ptr, или если это невозможно, shared_ptr. Хорошо написанный C ++ 11 короче, его легче читать и легче изучать, чем многие другие языки, когда речь заходит об управлении памятью.

Потому что современный C ++ не нуждается в сборке мусора.

Ответ Bjarne Stroustrup на часто задаваемые вопросы по этому вопросу гласит :

Я не люблю мусор. Я не люблю мусорить. Мой идеал - устранить необходимость в сборщике мусора, не производя мусор. Теперь это возможно.

Ситуация для кода, написанного в наши дни (C ++ 17 и в соответствии с официальными основными рекомендациями ), выглядит следующим образом:

• Большая часть кода, связанного с владением памятью, находится в библиотеках (особенно в тех, которые предоставляют контейнеры).
• В большинстве случаев использование кода, связанного с владением памятью, следует шаблону RAII , поэтому выделение производится при построении, а освобождение при уничтожении, что происходит при выходе из области, в которой что-то было выделено.
• Вы не выделяете или не выделяете память напрямую .
• Необработанные указатели не владеют памятью (если вы следовали рекомендациям), поэтому вы не сможете утечь, передав их.
• Если вам интересно, как вы собираетесь передавать начальные адреса последовательностей значений в памяти - вы будете делать это с помощью span ; необработанный указатель не требуется.
• Если вам действительно нужен собственный «указатель», вы используете умные указатели стандартной библиотеки C ++ - они не могут течь и прилично эффективны (хотя ABI может помешать этому). Кроме того, вы можете передать владение через границы области действия с помощью «указателей владельца» . Они необычны и должны использоваться явно; но когда они приняты - они позволяют проводить хорошую статическую проверку на предмет утечек.

"О да? Но как насчет ...

... если я просто напишу код так, как мы привыкли писать C ++ в старые времена? "

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

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

... если я reintrepret_cast? Или сделать сложную указательную арифметику? Или другие такие хаки?

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

1. Вы бы делали это редко (с точки зрения мест в коде, не обязательно с точки зрения доли времени выполнения)
2. Вы бы сделали это только намеренно, а не случайно.
3. Это будет выделяться в кодовой базе, соответствующей рекомендациям.
4. Это тот код, в котором вы все равно обойдете GC на другом языке.

... развитие библиотеки? "

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

Так вот, как сказал Бьярне: на самом деле вообще нет мотивации собирать мусор, как вы все, но старайтесь не производить мусор. GC становится не проблема с C ++.

_{Это не означает, что GC не является интересной проблемой для определенных конкретных приложений, когда вы хотите использовать собственные стратегии распределения и отмены распределения. Для тех, кто хотел бы иметь пользовательское распределение и удаление, а не GC уровня языка.}

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

Ничто не мешает вам использовать некоторые умные указатели, которые связаны с каким-то сторонним механизмом сборки мусора. Кажется, я вспоминаю, как Microsoft делала что-то подобное с COM, и это не очень хорошо.

Чтобы ответить на большинство вопросов «почему» о C ++, прочитайте « Дизайн и эволюция C ++».

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

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

Интересная особенность многих сборок мусора состоит в том, что ссылка на объект определяется не битовыми шаблонами, содержащимися в нем, а отношениями между битами, содержащимися в ссылке на объект, и другой информацией, хранящейся в другом месте. В C и C ++, если битовый шаблон, хранящийся в указателе, идентифицирует объект, этот битовый шаблон будет идентифицировать этот объект, пока объект не будет явно уничтожен. В типичной системе GC объект может быть представлен битовым шаблоном 0x1234ABCD в один момент времени, но следующий цикл GC может заменить все ссылки на 0x1234ABCD ссылками на 0x4321BABE, после чего объект будет представлен последним шаблоном. Даже если нужно отобразить битовый шаблон, связанный со ссылкой на объект, а затем прочитать его обратно с клавиатуры,

Все технические разговоры слишком усложняют концепцию.

Если вы автоматически включите GC в C ++ для всей памяти, тогда рассмотрите что-то вроде веб-браузера. Веб-браузер должен загрузить полный веб-документ и запустить веб-скрипты. Вы можете хранить переменные веб-скрипта в дереве документа. В БОЛЬШОМ документе в браузере с большим количеством открытых вкладок это означает, что каждый раз, когда сборщик мусора должен сделать полную коллекцию, он также должен сканировать все элементы документа.

На большинстве компьютеров это означает, что PAGE FAULTS произойдет. Таким образом, основная причина, чтобы ответить на этот вопрос, заключается в том, что ошибки страницы произойдут. Вы будете знать это, как когда ваш компьютер начнет делать много доступа к диску. Это потому, что GC должен коснуться большого количества памяти, чтобы доказать недействительные указатели. Когда у вас есть добросовестное приложение, использующее много памяти, необходимость сканировать все объекты каждой коллекции приводит к хаосу из-за ошибок страницы. Ошибка страницы - это когда виртуальная память должна быть прочитана обратно в оперативную память с диска.

Таким образом, правильное решение состоит в том, чтобы разделить приложение на части, которые нуждаются в GC, и части, которые не нуждаются. В приведенном выше примере с веб-браузером, если дерево документа было выделено с помощью malloc, но javascript работал с GC, то каждый раз, когда GC запускает его, сканируется только небольшая часть памяти и все элементы PAGED OUT памяти для дерево документов не нужно возвращать обратно.

Чтобы лучше понять эту проблему, посмотрите на виртуальную память и то, как она реализована на компьютерах. Все дело в том, что 2 ГБ доступно программе, когда на самом деле не так много оперативной памяти. На современных компьютерах с 2 ГБ ОЗУ для 32-битной системы это не такая проблема, если запущена только одна программа.

В качестве дополнительного примера рассмотрим полную коллекцию, которая должна отслеживать все объекты. Сначала вы должны проверить все объекты, доступные через корни. Затем просканируйте все объекты, видимые на шаге 1. Затем просмотрите ожидающие деструкторы. Затем снова перейдите на все страницы и отключите все невидимые объекты. Это означает, что многие страницы могут выгружаться и возвращаться в несколько раз.

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

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

КОРОТКИЙ ОТВЕТ: Мы не знаем, как эффективно выполнять сборку мусора (с небольшими временными и пространственными издержками) и правильно все время (во всех возможных случаях).

ДОЛГО ОТВЕТ: Как и C, C ++ - системный язык; это означает, что он используется, когда вы пишете системный код, например, операционную систему. Другими словами, C ++, как и C, разработан с максимально возможной производительностью в качестве основной цели. Стандарт языка не добавляет никаких функций, которые могут помешать достижению цели.

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

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

Когда мы сравниваем C ++ с Java, мы видим, что C ++ не был разработан с неявной сборкой мусора, в то время как Java была.

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

В дополнение к этому, C ++ - это язык, который предназначен для запуска в качестве автономного исполняемого файла вместо сложной среды выполнения.

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

Главным образом по двум причинам:

1. Потому что это не нужно (ИМХО)
2. Потому что это в значительной степени несовместимо с RAII, который является краеугольным камнем C ++

C ++ уже предлагает ручное управление памятью, выделение стека, RAII, контейнеры, автоматические указатели, умные указатели ... Этого должно быть достаточно. Сборщики мусора предназначены для ленивых программистов, которые не хотят тратить 5 минут на размышления о том, кто должен владеть какими объектами и когда следует освобождать ресурсы. Это не так, как мы делаем вещи в C ++.

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

Если вы посмотрите, как обрабатываются строки на языке со сборщиком мусора, вы обнаружите, что они ТОЛЬКО допускают высокоуровневые функции работы со строками и не разрешают двоичный доступ к строкам. Проще говоря, все строковые функции сначала проверяют указатели, чтобы увидеть, где находится строка, даже если вы только вытягиваете байт. Поэтому, если вы выполняете цикл, который обрабатывает каждый байт в строке на языке со сборкой мусора, он должен вычислить базовое местоположение плюс смещение для каждой итерации, потому что он не может знать, когда строка была перемещена. Тогда вы должны думать о кучах, стеках, потоках и т. Д. И т. Д.