guia - Regenerador de basura C++ 11: por qué y cómo
qgis español (2)
En la lista de características de lenguaje de C ++ 11 hay:
Soporte mínimo para la recolección de basura y la detección de fugas basada en la accesibilidad
(pero parece que no está implementado ni en GCC ni en Clang).
¿Por qué el comité estándar introdujo esta característica de lenguaje C + de recolección de basura?
¿C ++ realmente necesita un GC? ¿No es el RAII un patrón tan excelente (que se puede usar de manera uniforme tanto para recursos de memoria como para recursos que no son de memoria, como tomas de corriente, archivos, texturas ...)?
¿Romperá un GC la uniformidad del patrón de código C ++ que usa RAII?
Algunas personas dicen que un GC puede ser útil para romper dependencias circulares, pero ¿no es correcto utilizar punteros inteligentes como weak_ptr para este propósito?
¿Y qué sucede en caso de excepciones lanzadas? ¿Cómo se modificará la semántica de desenrollado de la pila para tener en cuenta un GC?
¿Y también se presentará un patrón IDisposable C #?
Además, suponiendo que se introduce un GC en C ++, ¿la sintaxis del puntero será diferente? Por ejemplo, ¿tendremos algunos "indicadores" tipo "sombrero" ^ como en las extensiones C ++ / CLI o C ++ / CX? Debería haber una manera de diferenciarse de punteros crudos ordinarios frente a punteros "gestionados", ¿verdad?
De Bjarne Stroustrup:
En realidad, lo que dije fue algo así como "Cuando (no si) la recolección automática de basura se vuelve parte de C ++, será opcional".
La propuesta no introduce un recolector de basura, solo lo permite en ciertas situaciones si la implementación lo elige . El estándar simplemente describirá estas situaciones como causantes de un comportamiento indefinido. Al hacer esto, se relajan los requisitos de la implementación, dando el margen mínimo para un recolector de basura.
El ejemplo simple dado en la propuesta considera cuando toma un puntero a un objeto dinámicamente asignado, XOR con otro valor, ocultando así el valor del puntero, y luego recupera el valor del puntero original para acceder al objeto a través de él. Antes de C ++ 11, esto estaría perfectamente bien y aún sería válido de usar. Sin embargo, ahora tal operación puede ser (ver el siguiente párrafo) considerado comportamiento indefinido, lo que significa que una implementación puede hacer recolección de basura en el objeto que se señaló.
El estándar establece que una implementación puede tener una seguridad de puntero más relajada , en cuyo caso el comportamiento es el mismo que antes, o la seguridad estricta del puntero , que permite la introducción de un recolector de basura.
Una implementación puede tener la seguridad de un puntero relajado , en cuyo caso la validez de un valor de puntero no depende de si es un valor de puntero derivado de forma segura. Alternativamente, una implementación puede tener seguridad estricta de puntero , en cuyo caso un valor de puntero que no es un valor de puntero derivado de manera segura es un valor de puntero no válido a menos que el objeto completo al que se hace referencia tenga una duración de almacenamiento dinámico y haya sido previamente declarado alcanzable (20.6.4 ) [...] Es la implementación definida si una implementación tiene una seguridad de puntero relajada o estricta.
Un valor de puntero es un valor de puntero derivado de manera segura si apunta a un objeto dinámicamente asignado y no le ha sucedido ningún negocio extraño (definido más específicamente en §3.7.4.3).
Si su implementación tiene la seguridad de un puntero estricto y aún desea hacer dicho negocio divertido a un puntero sin introducir un comportamiento indefinido, puede declarar que un puntero p es accesible de esta forma:
declare_reachable(p);
Esta función se define en el encabezado <memory> , junto con funciones relacionadas como undeclare_reachable , declare_no_pointers y undeclare_no_pointers . También puede determinar la rigurosidad de su implementación usando get_pointer_safety .