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