¿Cuál es el punto de vinculación temporal a una declaración de por vida del miembro en C++ Standard?

Question

En this question usuario Happy Mittal sección 12.2.5 cotizaciones de C++ 03 estándar: Un temporal ligado a un miembro de referencia en ctor-inicializador de un constructor (12.6.2) persiste hasta que el constructor sale.

¿Cómo puede ser útil de todos modos? Quiero decir que una vez que el constructor sale, el temporal se destruye, pero la referencia permanece vinculada, ahora a un objeto ya destruido.

¿Cuál es el punto de especificar cuidadosamente la vida útil temporal si todavía hay una referencia colgante para toda la vida útil del objeto externo? ¿En qué escenario puede ser útil este comportamiento?

Answer 1

No es útil tener un miembro de referencia vinculado a un objeto muerto, pero es útil aclarar que la extensión de duración temporal "normal" cuando se vincula a una referencia no se aplica en este caso.

También especifica la extensión de la vida útil temporal que se aplica especialmente en el inicializador de ctor: se extiende hasta el final del ctor en lugar de morir antes de que se ejecute el cuerpo del ctor. Esto no sería útil, excepto en las clases "inteligentes" cuyo punto entero es ejecutar el ctor, y este tipo de uso (ab) se evita correctamente.

No conozco ningún ejemplo del mundo real de este último, pero me parece similar a tener destructores nothrow por defecto rompió las clases que fueron "inteligentes" en su vida y cómo fueron utilizados. Esto sí tenía usos en el mundo real y came up en discusiones sobre cómo manejar la semántica predeterminada de dtors en C++ 0x.

Answer 2

En lenguaje D, el proceso de construcción puede escribirse libremente en cierto grado. Sin embargo, en C++, el orden de construcción/inicialización está estrictamente estipulado. Entonces, si la inicialización de la clase requiere algún cálculo costoso, un código como a veces puede ser válido como una solución reacia.

struct S { 
    Args const &r; 
    A a; 
    B b; 
    S(args....) 
    : r(expensive_func(args....)), a(r.for_a), b(r.for_b) {} 
}; 

Answer 3

Es útil para escritores de compiladores. Ya tienen la lógica en su lugar para destruir temporales vinculados al final de un ámbito, y la salida del constructor es uno de esos puntos. Con esta regla los compiladores pueden reutilizar ese punto para destruir dichos temporales también.

Tenga en cuenta que la norma realmente debería decidir sobre algún tipo de vida, y el único otro punto razonable sería después de la lista del inicializador del ctor pero antes del cuerpo del ctor. Ese no es un punto donde los temporales se destruirían de lo contrario, y podría interferir con los bloques de función try {} catch() (que incluyen la lista de inicializadores del ctor)