Существуют ли практические применения С++ 11 Garbage Collection ABI?

С++ 11 представил интерфейс для сборщиков мусора. Из того, что я вижу, он обеспечивает стандартизированный способ связи с GC (например, declare_no_pointers) и получать информацию о том, как обрабатываются замаскированные указатели (например, get_pointer_safety).

Однако в С++ 11 нет стандартизованного способа выделения выделенного блока памяти, который вам не нужно освобождать вручную. Есть случаи, когда это поможет, даже если деструкторы не вызываются. Одним из примеров является внедрение эффективных параллельных структур данных (как упоминалось Herb Sutter) без необходимости обработки сложных протоколов очистки.

До сих пор так хорошо. Мой вопрос (с точки зрения обычного разработчика, а не разработчика библиотеки GC):

Есть ли реальный пример, где вам помог новый интерфейс GC С++ 11?

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

(В долгосрочной перспективе общий интерфейс, определенный стандартом С++ 11, надеется, что он будет окупаться. Однако мой вопрос нацелен только на ближайшее будущее.)

Ответ 1

Нет, в настоящее время нет практического использования интерфейса С++ 11 GC, так как нет компилятора, который полностью поддерживает этот API за это время. Кроме того, стандарт С++ 11 объявляет этот API как необязательный, и нет движения, которое можно было бы реализовать в основных компиляторах (но, как отмечает Джесси Хороший, MSVC уже поддерживает его).

Также вы должны посмотреть этот пост, он имеет соответствующую информацию: Почему сборка мусора, когда доступна RAII?

Ответ 2

std::shared_ptr предоставляет так называемую сборку мусора с подсчетом ссылок. Это просто реализовать, но имеет некоторые недостатки. В частности, он менее эффективен, чем альтернативные формы сбора мусора во многих приложениях, и, что более важно, он не может обрабатывать циклические ссылки.

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

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

Те, кто заявляет "зачем вы хотите сбор мусора, когда у вас RAII", запутались. RAII - одна из возможных моделей памяти, которая использует концепцию собственности. Каждый объект должен принадлежать только одному другому объекту, и этот владелец отвечает за его срок службы. Для многих объектных моделей это просто не является естественным или приемлемым, так как один объект ссылается на несколько других, и нет четкого владельца. Для многих приложений вы хотите, чтобы срок жизни объектов заканчивался автоматически, как только он становится неучтенным, и именно так работают Java и С# по умолчанию.

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