Метод, используемый в стороннем сборщике мусора

Question

Я пишу, чтобы уточнить некоторые комментарии на этом сайте.

1) Я знаю, что в C ++ нет сборщика мусора. Один из них сказал, что C ++ был изобретен еще до идеи сборщика мусора, и в этом причина. Это правда? Я думаю, что это имеет смысл.

2) Всякий раз, когда обсуждался сборщик мусора, умная точка (такая как boost :: share_ptr) была выбрана как способ. Однажды я был убежден, что подсчет ссылок является одним из способов реализации сборщика мусора, но некоторые говорили, что «умная точка» не является реализацией сборщика мусора. В чем дело?

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

Я благодарен, если кто-нибудь может прояснить мои заблуждения.

Большое спасибо!

Answer 1

1. нет, сборка мусора намного старше C ++ (в частности, во многих версиях Lisp это было в 60-х).

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

3. сборщик Boehm для C и C ++ использует консервативный подход: вкратце, все, что выглядит как адрес, принимается за единицу (так, что бы это ни значило) чтобы "не собиралось". Прочтите страницу по указанному мною URL-адресу и его исходящим ссылкам, чтобы получить гораздо больше информации по этому вопросу.

Answer 2

1. Как указал Алекс, LISP собирал мусор задолго до того, как был изобретен C ++. OTOH, некоторые из этих ранних реализаций использовали подсчет ссылок.

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

   struct node { узел * следующий; };

   узел * узел1 = новый узел, узел2 = новый узел;

   узел1-> следующий = узел2; узел2-> следующий = узел1;

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

3. Когда вы используете сторонние сборщики мусора с C ++, результат больше (совсем) не соответствует реализации C ++. Например, если вы «крутите» указатель (например, инвертируете все его биты), GC не распознает, на что он указывает. Когда вы «распутываете» его (взмахиваете битами назад), то, на что оно указывало, может больше не существовать. Однако проблемы в реальном коде достаточно необычны, и люди регулярно используют GC без проблем.

   OTOH, есть и ограничения, поэтому большинство сборщиков мусора для C и C ++ тоже не очень хорошо работают. Самые последние разработки GC работают путем копирования объектов, которые все еще существуют, поэтому они все смежны в куче после выполнения цикла GC. Чтобы сделать это, он должен «исправить» все указатели на этот объект, чтобы они указывали на новый адрес. Поскольку GC с C или C ++ не знает наверняка, что это указатель или нет, он не может что-то изменить (если что-то не является указателем), поэтому он должен оставлять объекты на месте, что снижает производительность. *

Были некоторые серьезные дискуссии о добавлении GC в C ++. Два comp.lang.c ++. Модерируемый Темы может быть интересно. Предупреждение: они довольно длинные, и некоторые аргументы повторяются несколько раз в нескольких случаях. OTOH, они указывают на некоторые реальные проблемы и возможные решения.

Answer 3

Относительно 1 и в меньшей степени 2:

Это краткое, но хорошее объяснение.

http://www.devx.com/tips/Tip/12766

Кроме того, здесь есть аналогичный вопрос о теме.

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

Проверьте их.

Answer 4

Минимальная поддержка для сборки мусора - но без сборщика мусора - будет добавлена ​​к следующему стандарту C ++ (неофициально называется C ++ 0x). Вот хорошая статья об этом: http://www.hpl.hp.com/techreports/2009/HPL-2009-360.pdf

Answer 5

Согласно http://en.wikipedia.org/wiki/Garbage_collection_%28computer_science%29 Сборка мусора была изобретена в 1959 году, что значительно предшествовало появлению C ++.

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