Сборка мусора в C ++ 11

Минимальная поддержка GC (n2670) означает только такие функции, как std::declare_reachable включены, и определяют, что означает «безопасный указатель», поэтому выполнение определенных операций, таких как значения указателя XOR, становится неопределенным поведением, и GC не нужно беспокоиться об этом. Смотрите также Bjarne Stroustrup C ++ 11 FAQ по GC ABI, а также n2585: минимальная поддержка мусора
Обнаружение утечек на основе сбора и достижимости.

Предложение позволяет GC быть реализованным в рамках C ++ 11. Но само предложение не означает, что реализация должна поддерживать GC. Некоторая библиотека, например libc ++ просто реализует библиотечные функции как no-op.

Я почти уверен, на данный момент, память в вашем случае просто утечка. Но обратите внимание, что деструктор действительно не требуется для запуска, когда происходит GC. Предполагая, что «§3.8 времени жизни объекта» также предоставляет указатели GC-ed, мы имеем (§3.8 / 4):

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

Также возможно, что память уже освобождена без вызова деструктора. На самом деле, более ранние предложения GC, такие как n2310: прозрачный сборщик мусора для C ++ прямо заявляет, что (n2310 §7)

Когда объект утилизируется сборщиком мусора, его деструктор не вызывается (из
Конечно, явное удаление всегда вызывает деструкторы).