Inicialización de miembro para variable no copiable en C++ 17

initialization language-lawyer

Question

Al realizar la inicialización de miembros para una variable no copiable (como std::atomic<int> ), se requiere utilizar direct-initialization lugar de la direct-initialization de copy-initialization según la respuesta here . Sin embargo, cuando -std=c++17 en g++ 7.4.0 , parece que este último también funciona bien.

#include <atomic>

class A {
    std::atomic<int> a = 0;     // copy-initialization
    std::atomic<int> b{0};      // direct-initialization
};

$ g++ -c atomic.cc -std=c++11    // or c++14
atomic.cc:4:26: error: use of deleted function ‘std::atomic<int>::atomic(const std::atomic<int>&)’
     std::atomic<int> a = 0;     // copy-initialization

$ g++ -c atomic.cc -std=c++17
// no error

También falló al compilar con g++ 6.5.0 incluso con -std=c++17 . ¿Cuál es el correcto aquí?

Answer 1

¿Cuál es el correcto aquí?

El 7.4.0 es correcto. La copia se puede elidir para este caso, por lo que está bien. (aunque esto requiere c ++ 17 ).

(consulte https://en.cppreference.com/w/cpp/language/copy_initialization para obtener más detalles)

Answer 2

El comportamiento cambió desde C ++ 17, lo que requiere que los compiladores omitan la construcción copiar / mover en std::atomic<int> a = 0; , es decir, copia garantizada de elisión .

(énfasis mío)

En las siguientes circunstancias, se requiere que los compiladores omitan la construcción de copiar y mover objetos de clase, incluso si el constructor de copiar / mover y el destructor tienen efectos secundarios observables. Los objetos se construyen directamente en el almacenamiento donde, de lo contrario, se copiarían / ​​moverían. Los constructores de copiar / mover no necesitan estar presentes o accesibles, ya que las reglas del lenguaje aseguran que no se realice ninguna operación de copiar / mover, incluso conceptualmente :

En detalles, std::atomic<int> a = 0; realiza la inicialización de la copia :

Si T es un tipo de clase, y la versión no calificada por cv del tipo de otro no es T o derivada de T, o si T es un tipo que no es de clase, pero el tipo de otro es un tipo de clase, secuencias de conversión definidas por el usuario que pueden convertirse del tipo de otro a T (o a un tipo derivado de T si T es un tipo de clase y hay una función de conversión disponible) se examinan y se selecciona el mejor mediante resolución de sobrecarga. El resultado de la conversión, que es una prvalue temporary (until C++17) prvalue expression (since C++17) si se utilizó un constructor de conversión, se usa para inicializar directamente el objeto.

y

(énfasis mío)

si T es un tipo de clase y el inicializador es una expresión prvalue cuyo tipo no calificado de cv es la misma clase que T, la expresión inicializadora en sí, en lugar de una materializada temporalmente, se utiliza para inicializar el objeto de destino

Eso significa que a se inicializa desde 0 directamente, no hay que construir temporalmente y luego ya no es temporal para copiar / mover.

Antes de C ++ 17, en concepto std::atomic<int> a = 0; requiere que se construya un std::atomic temporal a partir de 0 , luego el temporal se usa para copiar-construir a .

Incluso se permite copiar elisión antes de C ++ 17, se considera como una optimización:

(énfasis mío)

Esta es una optimización: incluso cuando se lleva a cabo y no se llama al constructor copiar / move (since C++11) , todavía debe estar presente y accesible (como si no hubiera sucedido ninguna optimización), de lo contrario, el programa está mal formado :

Es por eso que gcc activa el diagnóstico en modo pre-c ++ 17 para std::atomic<int> a = 0; .

(énfasis mío)

Nota: la regla anterior no especifica una optimización: la especificación del lenguaje central de C ++ 17 de los valores y temporales es fundamentalmente diferente de la de las revisiones anteriores de C ++: ya no hay un temporal para copiar / mover . Otra forma de describir la mecánica de C ++ 17 es el "paso de valor no materializado": los valores se devuelven y se utilizan sin materializar nunca un temporal .

^{Por cierto: supongo que hubo un error en g++ 6.5.0 con -std=c++17 ; y se ha solucionado en una versión posterior.}