C ++ 11のガベージコレクション
私は、特にVisual Studio 2010で、C++ 11のさまざまな機能を調べて遊んでいます。
言及されていることの1つは 最小限のガベージコレクション ：
これによると ブログ投稿 、VC10はこの機能をサポートしています。
私のテストでは、失われたオブジェクトに対してデストラクタが呼び出されないことが示されているため、それらのメモリ位置が解放されているかどうか、またはリークしているかどうかはわかりません。
私は決してそれに依存するつもりはありませんが、その振る舞いについての明確で決定的な答えを見つけることができませんでした。
最小限のGCサポート（n2670）は、 std::declare_reachable が含まれ、「安全に派生したポインター」の意味を定義するため、ポインター値のXORなどの特定の操作を行うと未定義の動作になり、GCはそれについて心配する必要がありません。参照 BjarneStroustrupのC++ 11 FAQ GC ABI 、および n2585：ガベージコレクションと到達可能性ベースのリーク検出の最小限のサポート =。
この提案により、GCをC++ 11のフレームワーク内に実装できます。しかし、提案自体は、実装がGCをサポートする必要があることを意味するものではありません。一部のライブラリ（例： libc ++は、ライブラリ関数をno-opとして実装するだけです。
この時点で、あなたのケースのメモリがリークされただけだと確信しています。ただし、GCが発生したときにデストラクタを実行する必要はないことに注意してください。 「§3.8オブジェクトの有効期間」がGC-edポインタにも提供されると仮定すると、次のようになります（§3.8/ 4）。
...重要なデストラクタを持つクラスタイプのオブジェクトの場合、オブジェクトが占有するストレージが再利用または解放される前に、プログラムがデストラクタを明示的に呼び出す必要はありません;ただし、デストラクタへの明示的な呼び出しがない場合、または削除式（5.3.5）を使用してストレージを解放しない場合、デストラクタは暗黙的に呼び出されないものとし、デストラクタによって生成される副作用に依存するプログラムはありません。未定義の動作があります。
したがって、デストラクタを呼び出さなくても、メモリがすでに解放されている可能性もあります。実際、 n2310：C++用の透過的なプログラマー向けガベージコレクション などの以前のGC提案では、（n2310§7）と明示的に述べられています。
オブジェクトがガベージコレクターによってリサイクルされる場合、そのデストラクタは呼び出されません（もちろん、明示的な削除は常にデストラクタを呼び出します）。