De operadores de asignación misiones y compuestos [expr.ass]
El significado de x = {v}, donde T es el tipo escalar de la expresión x, es el de x = T (v) excepto que no se permite ninguna conversión de estrechamiento (8.5.4).
y desde Lista-inicialización [dcl.ini.list]
Si se requiere una conversión de restricción (véase a continuación) para convertir cualquiera de los argumentos, el programa es tratos formado.
Así que, básicamente, no puede ignorarlo, su programa está mal formado en presencia de reducciones de conversiones.
De cumplimiento Implementación: Es necesario
Implementaciones para diagnosticar programas que uso de tales extensiones que se forman mal de acuerdo con esta Norma Internacional. Sin embargo, una vez hecho esto, pueden compilar y ejecutar dichos programas.
Bjarne Stroustroup decir this:
La prevención de estrechamiento
El problema: C y C++ implícitamente trunca:
int x = 7.3; // Ouch!
void f(int);
f(7.3); // Ouch!
Sin embargo , En C++ 0x, {} inicialización no estrecho:
int x0 {7.3}; // error: narrowing
int x1 = {7.3}; // error: narrowing
double d = 7;
int x2{d}; // error: narrowing (double to int)
char x3{7}; // ok: even though 7 is an int, this is not narrowing
vector<int> vi = { 1, 2.3, 4, 5.6 }; // error: double to int narrowing
La forma C++ 0x evita un montón de incompatibilidades es apoyándose en los valores reales de inicializadores (tales como 7 en el ejemplo anterior) cuando puede (y no solo escribe) al decidir qué es una conversión de reducción. Si un valor se puede representar exactamente como el tipo de destino, la conversión no se reduce.
char c1{7}; // OK: 7 is an int, but it fits in a char
char c2{77777}; // error: narrowing
Tenga en cuenta que en coma flotante a entero conversiones siempre se consideran estrechamiento - incluso 7,0 a 7.
Así pues, en cierto modo, el estrechamiento también aumenta la seguridad de tipos.
[Tu cohete podría explotar] (http://www.ima.umn.edu/~arnold/disasters/ariane.html) –
Si alguna vez trabajo en un cohete, me aseguraré de tenerlo en cuenta ;) –
Esto es algo que ha producido _warnings_ siempre, para siempre, y para siempre y un día, y es algo bueno. Ahora es un _error_, es discutible si eso es algo bueno ya que rompe la compilación del código existente, presumiblemente correcto. Sin embargo, evita algunos errores imposibles de rastrear, por lo que puedo ver el razonamiento. No desactivo esa lógica de error, porque cuando arrojas accidentalmente la mitad superior de un valor y tienen un significado, tu código sigue funcionando bien hasta que no funciona, y entonces no sabes por qué. – Damon