Reducir las conversiones en C++0x. ¿Soy solo yo, o esto suena como un cambio radical?

Me sorprendería y decepcionaría saber que cualquiera de los códigos C++ que escribí en los últimos 12 años tenía este tipo de problemas. Pero la mayoría de los compiladores habrían vomitado advertencias sobre cualquier "estrechamiento" en tiempo de compilación todo el tiempo, a menos que me esté perdiendo algo.

¿Estas también están reduciendo las conversiones?

unsigned short b[] = { -1, INT_MAX };

Si es así, creo que podrían aparecer un poco más a menudo que su ejemplo de tipo flotante a tipo integral.

No me sorprendería tanto si alguien fuera atrapado por algo como:

float ra[] = {0, CHAR_MAX, SHORT_MAX, INT_MAX, LONG_MAX};

(en mi implementación, los dos últimos no producen el mismo resultado cuando se convierten de nuevo a int / long, por lo tanto se están estrechando)

No recuerdo haber escrito esto. Solo es útil si una aproximación a los límites es útil para algo.

Esto parece al menos vagamente plausible también:

void some_function(int val1, int val2) {
    float asfloat[] = {val1, val2};    // not in C++0x
    double asdouble[] = {val1, val2};  // not in C++0x
    int asint[] = {val1, val2};        // OK
    // now do something with the arrays
}

Pero no es del todo convincente, porque si sé que tengo exactamente dos valores, ¿por qué ponerlos en matrices en lugar de simplemente float floatval1 = val1, floatval1 = val2;? ¿Cuál es la motivación, sin embargo, por qué debería compilarse (y funcionar, siempre que la pérdida de precisión esté dentro de la precisión aceptable para el programa), mientras que float asfloat[] = {val1, val2}; no debería? De cualquier manera estoy inicializando dos flotadores de dos ints, es sólo que en un caso los dos flotadores pasan a ser miembros de un agregado.

Eso parece particularmente duro en los casos en que una expresión no constante resulta en una conversión de estrechamiento a pesar de que (en un implementación particular), todos los valores del tipo de origen son representables en el tipo de destino y convertibles a sus valores originales:

char i = something();
static_assert(CHAR_BIT == 8);
double ra[] = {i}; // how is this worse than using a constant value?

Suponiendo que no hay ningún error, presumiblemente la solución es siempre hacer la conversión explícita. A menos que esté haciendo algo extraño con macros, creo que un inicializador de matriz solo aparece cerca del tipo de la matriz, o al menos a algo que representa el tipo, que podría depender de un parámetro de plantilla. Así que un yeso debe ser fácil, si es prolijo.

Un ejemplo práctico que he encontrado:

float x = 4.2; // an input argument
float a[2] = {x-0.5, x+0.5};

El literal numérico es implícitamente double que causa la promoción.

Los errores de conversión de estrechamiento interactúan mal con las reglas implícitas de promoción de enteros.

Tuve un error con el código que se parecía a

struct char_t {
    char a;
}

void function(char c, char d) {
    char_t a = { c+d };
}

Que produce un error de conversión de estrechamiento (que es correcto de acuerdo con el estándar). La razón es que c y d, implícitamente, promueven a int y el resultado int no puede ser reducido de nuevo a char en una lista de inicializador.

OTOH

void function(char c, char d) {
    char a = c+d;
}

Está por supuesto todavía bien (de lo contrario todo el infierno liberarse). Pero sorprendentemente, incluso

template<char c, char d>
void function() {
    char_t a = { c+d };
}

Está bien y compila sin advertencia si la suma de c y d es menor que CHAR_MAX. Todavía creo que esto es un defecto en C++11, pero la gente allí piensa lo contrario, posiblemente porque no es fácil de arreglar sin deshacerse de la conversión implícita de enteros (que es una reliquia del pasado, cuando la gente escribió código como char a=b*c/d y esperaba que funcionara incluso si (b*c) > CHAR_MAX) o errores de conversión de estrechamiento (que posiblemente sean algo bueno).

Intente agregar-Wno-narrowing a sus CFLAGS, por ejemplo:

CFLAGS += -std=c++0x -Wno-narrowing

Parece que GCC-4.7 ya no da errores para reducir las conversiones, sino advertencias.