2011-02-11 7 views
14

¿No debería estar bien usar static_cast para convertir int a bool, ya que convierte el reverso de la conversión implícita, pero sigo recibiendo una advertencia?¿Por qué lanzar una int a un bool da una advertencia?

Ejemplo:

MSVC++ 8

bool bit = static_cast<bool>(100); 
+2

Incluso con '-Wall -Wextra -ansi -pedantic', g ++ no se queja de esto. Qué compilador estas usando? Tal vez publicar el código preciso? – Thomas

+0

Tu elenco me asustó. – GManNickG

+0

Sí a mí también, editado. – user4344

Respuesta

45

El hecho de que la conversión a => b esté implícita no dice nada sobre la viabilidad del reverso, b => a.

En su caso, no debe lanzar en absoluto. Sólo hacer lo obvio: compara:

bool result = int_value != 0; 

Ésta es la única manera lógica correcta de convertir una int a bool y hace que el código mucho más fácil de leer (porque hace que los supuestos explícitos).

Lo mismo aplica para el reverso, por cierto. La conversión implícita de bool a int es muy vago. Hacer que la asignación explícita:

int result = condition ? 1 : 0; 
+3

Defina "correcto", por favor. ¿Quiere decir, el único permitido por su guía de estilo? –

+2

Sé que no es necesario, pero personalmente prefiero 'bool result = (int_value! = 0);' para la legibilidad – sashoalm

+0

@Steve Permitido por mi sentido estético, sí. He modificado la formulación, un poco. –

3

No estoy seguro de por qué sucede cuando lanzas explícitamente (creo que era una advertencia de rendimiento?), Pero que suelen utilizar código así para evitar advertencias:

int i; 
bool b = (0!=i); 

Esto nunca da advertencias.

8

Eso es entre usted y su compilador, pero Microsoft piensa que usted debe escribir:

i != 0 

con preferencia a cualquiera:

(bool)i 

o

static_cast<bool>(i) 

Las posibles razones para preferir que Incluye:

  • esta conversión no se comporta como otras conversiones de restricción, que tienen un módulo,
  • las conversiones implict a bool son también un poco de controversia: un montón de personas que prefieren hacer if (buf != NULL) o if (buf != 0) con preferencia a if (buf) después de una llamada a malloc,
  • la comparación es más corta y más clara.
+2

Acerca de su segundo punto: por mi parte, creo que es fundamentalmente diferente escribir una prueba 'if (ptr_value)' de escribir una prueba 'if (int_value)' - la primera está bien (en mi pequeño mundo) porque prueba a * estado * para validez mientras que el segundo no. –

+2

@Konrad: suficiente. Podría tener un número entero que se comporta de forma análoga a un puntero en ese sentido: 0 * es * un marcador de posición especial que significa "nada", después de todo. Pero la aritmética moderna lo ha domesticado para que sea solo otro valor, por lo que tiene razón en que el entero 0 a menudo no significa "no" en la forma en que lo hacen los punteros nulos. –

+0

"Microsoft cree que debe escribir": esta es una afirmación bastante audaz, ¿tiene alguna fuente para esto? –

-1

que hago como alguien ya publicado:

bool result = int_value != 0; 

Es la forma más fácil de la OMI y de la que es más intuitiva que tratar a emitir el número entero a bool.

+7

Bienvenido a SO! Tenga en cuenta que este es un sitio de preguntas y respuestas, y no un foro. No publique una respuesta para decir que está de acuerdo con otra respuesta. Una vez que tenga suficiente reputación, puede expresar su aprobación mediante votación ascendente. –

Cuestiones relacionadas