Destruye y luego construye un objeto nuevo usando la misma variable

Question

A veces es bueno empezar de nuevo. En C++ puedo emplear esta sencilla maniobra siguiente:

{ 

    T x(31, Blue, false); 

    x.~T();      // enough with the old x 

    ::new (&x) T(22, Brown, true); // in with the new! 

    // ... 
} 

Al final del alcance, el destructor se ejecutará una vez más y todo se vea bien. (Digamos también T es un poco especial y no le gusta ser asignado, ni mucho menos intercambiado.) Pero algo me dice que no siempre es sin riesgo destruir todo e intentar de nuevo. ¿Hay una posible captura con este enfoque?

Answer 1

creo que la única manera de hacer esto realmente es seguro de usar para exigir al constructor llamado a ser noexcept, por ejemplo mediante la adición de un static_assert:

static_assert(noexcept(T(22, Brown, true)), "The constructor must be noexcept for inplace reconstruction"); 
T x(31, Blue, false); 
x.~T(); 
::new (&x) T(22, Brown, true); 

Por supuesto, esto sólo funcionará para C++ 11.

Answer 2

Si el constructor de T lanza en la segunda construcción, tiene un problema. Si te gustan los enfoques de fuerza bruta, verifica esto:

T x(31, Blue, false); 
x.~T(); 
const volatile bool _ = true; 
for(;_;){ 
    try{ 
    ::new (&x) T(22, Brown, true); 
    break; // finally! 
    }catch(...){ 
    continue; // until it works, dammit! 
    } 
} 

¡Incluso proporciona la fuerte excepción de garantía!

---

En una nota más seria, es como pisar una mina, a sabiendas de que se apagará si se mueve el pie ...

Y no es en realidad una forma de evitar el comportamiento indefinido de la doble destrucción aquí:

#include <cstdlib> 

T x(31, Blue, false); 
x.~T(); 
try{ 
    ::new (&x) T(22, Brown, true); 
}catch(...){ 
    std::exit(1); // doesn't call destructors of automatic objects 
} 

Answer 3

Si la expresión de construcción de T arroja, se duplicará la destrucción del objeto, que es UB. Por supuesto, incluso el deseo de hacer esto es indicativo de una falla de diseño.

Answer 4

Intenté compilarlo, pero solo me atreví a ejecutarlo bajo depurador. Así que eché un vistazo al desmontaje de mi compilador anterior generado (los comentarios son del compilador también):

@1 sub nerve.cells, fa0h 
@2 xor x, x  // bitch. 
@3 mov out, x 
@4 test out, out 
@5 jne @1 
@6 xor x, x  // just in case. 
@7 sub money, 2BC // dammit. 
@8 mov %x, new.one 
@8 cmp new.one, %x 
@9 jne @7 
... 
@25 jmp @1  // sigh... 

Answer 5

Mmm. Ya que está haciendo todo lo que C++ desalienta, creo que todo el mundo se está olvidando de goto.

Tenga en cuenta que después de la explícita X.~T() llamada, y antes de que se reconstruye , todavía habría doble quebrantamiento si alguien hizo un goto que antes de la declaración/inicialización de la variable x (incluso dentro de la sección Cobertura del interior).

Como obviamente podrías documentar eso, no pasaré por la molestia de tratar de "arreglarlo". Podría, conceptualmente, diseñar una clase RAII para gestionar la reconstrucción de objetos en el lugar, haciendo que esta maniobra sea segura para los goto en cualquier lugar. Tenga en cuenta que puede hacer que la llamada de constructor de ubicación-nueva se reenvíe perfectamente desde el destructor del objeto administrador RAII. La vida es buena.

Las otras advertencias se siguen aplicando, por supuesto (ver otras respuestas)

---

podemos asumir nothrow constuction para este momento

Answer 6

No hay nada que le impida hacer esto, lo hará trabajo en la mayoría de los casos. Pero como es el caso en una gran cantidad de C++ sabiendo que los detalles de sus casos será la diferencia entre que funcione como desee y un volcado de núcleo. Hay muy pocos ejemplos de razones por las que podría ver por qué querría hacer esto en un programa real, el único que tiene sentido es un archivo mapeado en la memoria.