recolección de basura en C++ 11

Question

He estado buscando a través y jugando con diferentes características de C++ 11, específicamente en Visual Studio 2010.

Una de las cosas que se mencionan es minimal garbage collection:

Según este blog post, VC10 es compatible con esta función.

Mis pruebas muestran que el destructor no se invoca en los objetos que se pierden, por lo que no estoy seguro de si su ubicación de memoria se ha liberado o si tienen fugas.

No tengo intención de depender de él, de ninguna manera, pero no pude encontrar una respuesta directa y definitiva sobre su comportamiento.

Answer 1

apoyo GC mínima (N2670) sólo significa funciones como std::declare_reachable se incluyen y definen lo que es el significado de "puntero segura de origen", por lo que hacer ciertas operaciones como XOR-ing valores de puntero se convierte en un comportamiento indefinido y la GC Don No tienes que preocuparte por eso. Consulte también Bjarne Stroustrup's C++11 FAQ on the GC ABI y n2585: Minimal Support for Garbage Collection and Reachability-Based Leak Detection.

La propuesta permite implementar un GC dentro del marco de C++ 11. Pero la propuesta en sí misma no significa que la implementación necesita ser compatible con GC. Algunas bibliotecas, p. libC++ simplemente implementa las funciones de la biblioteca como no-op.

Estoy bastante seguro, en este momento, la memoria en su caso se ha filtrado. Pero observe que el destructor no está obligado a ejecutar cuando ocurre GC. Asumiendo "§3.8 Objeto vida" también suministra a los punteros GC-ed, tenemos (§3.8/4):

... Para un objeto de un tipo de clase con un destructor no trivial, el programa no es necesario llamar al destructor explícitamente antes de que el almacenamiento que ocupa el objeto se reutilice o se libere; sin embargo, si no hay una llamada explícita al destructor o si una expresión de eliminación (5.3.5) no se utiliza para liberar el almacenamiento, el destructor no se llamará implícitamente y cualquier programa que dependa de los efectos secundarios producidos por el destructor tiene un comportamiento indefinido

Por lo tanto, también es posible que la memoria ya se haya liberado sin llamar al destructor. De hecho, las propuestas anteriores de GC como n2310: Transparent Programmer-Directed Garbage Collection for C++ afirma explícitamente que (N2310 § 7)

Cuando un objeto se recicla por el recolector de basura, su destructor no se invoca (De supuesto, la supresión explícita invoca siempre destructores).