Ответ 1
Минимальная поддержка GC (n2670) включает только функции, такие как std::declare_reachable, и определить, что означает "безопасный производный указатель", поэтому некоторые операции, такие как значения указателя XOR-ing, становятся undefined, и GC не нужно беспокоиться об этом. См. Также Bjarne Stroustrup С++ 11 FAQ по GC ABI и n2585: минимальная поддержка мусора
Обнаружение утечки на основе коллекции и на основе достижимости.
Предложение позволяет использовать GC в рамках С++ 11. Но само предложение не означает, что реализация должна поддерживать GC. Некоторая библиотека, например. libС++ просто реализует функции библиотеки как no-op.
Я уверен, на данный момент память в вашем случае просто просочилась. Но обратите внимание, что деструктор действительно не требуется запускать, когда происходит GC. Предполагая, что "§3.8 Время жизни объекта" также поставляет на указатели GC-ed, мы имеем (§3.8/4):
... Для объекта типа класса с нетривиальным деструктором программа не требует прямого вызова деструктора до того, как хранилище, которое объект занимает, будет повторно использовано или выпущено; однако, если нет явного вызова деструктора или если выражение удаления (5.3.5) не используется для освобождения хранилища, деструктор не должен быть неявно вызван и любая программа, зависящая от побочных эффектов, создаваемых деструктором имеет поведение undefined.
Таким образом, также возможно, что память уже освобождена без вызова деструктора. На самом деле, более ранние предложения GC, такие как n2310: Прозрачная программа-сборщик мусора для С++ явно заявляют, что (n2310 §7)
Когда объект перерабатывается сборщиком мусора, его деструктор не вызывается (Of Конечно, явное удаление всегда вызывает деструкторы).