Cómo evitar cuidadosamente C echa a perder la verdad

Question

Estoy muy feliz de que, en C, este tipo de cosas son malas código:

(var_a == var_b) ? TRUE : FALSE 

Sin embargo, ¿cuál es la mejor manera de tratar con esto:

/* Header stuff */ 
#define INTERESTING_FLAG 0x80000000 
typedef short int BOOL; 

void func(BOOL); 

/* Code */ 
int main(int argc, char *argv[]) 
{ 
     unsigned long int flags = 0x00000000; 

     ... /* Various bits of flag processing */ 

     func(flags & INTERESTING_FLAG); /* func never receives a non-zero value 
             * as the top bits are cut off when the 
             * argument is cast down to a short 
             * int 
             */ 
} 

¿Es aceptable (para cualquier valor de aceptable que esté utilizando) tener (flags & FLAG_CONST) ? TRUE : FALSE?

Answer 1

Preferiría (flags & CONST_FLAG) != 0. Mejor aún, use el tipo _Bool si lo tiene (aunque a menudo se disfraza como bool).

Answer 2

Se puede evitar esto, un par de diferentes maneras:

En primer lugar

void func(unsigned long int); 

se haría cargo de ella ...

O

if(flags & INTERESTING_FLAG) 
{ 
    func(true); 
} 
else 
{ 
    func(false); 
} 

también lo haría .

EDITAR: (flags & INTERESTING_FLAG) != 0 también es bueno. Probablemente mejor.

Answer 3

Establezca las banderas del compilador lo más analíticamente posible, para advertirle de cualquier lanzamiento que pierda bits, y trate las advertencias como errores.

Answer 4

En cualquier caso, llamaría func con (flags & INTERESTING_FLAG) != 0 como argumento para indicar que se requiere un parámetro booleano y no el resultado aritmético de flags & INTERESTING_FLAG.

Answer 5

Esto es parcialmente fuera de tema:

También me gustaría crear una función de ayuda que hace que sea obvio para el lector cuál es el propósito de la comprobación es por lo que no llena su código con esta bandera explícita la comprobación de todo sobre el lugar. Typedefing the flag type haría más fácil cambiar el tipo de bandera y la implementación más tarde.

Los compiladores modernos admiten la palabra clave en línea que puede eliminar la sobrecarga del rendimiento en una llamada a función.

typedef unsigned long int flagtype; 
... 
inline bool hasInterestingFlag(flagtype flags) { 
    return ((flags & INTERESTING_FLAG) != 0); 
} 

Answer 6

Puede que esta no sea una solución popular, pero a veces las macros son útiles.

#define to_bool(x) (!!(x)) 

Ahora podemos tener todo lo que queremos de forma segura sin temor a rebosar nuestro tipo:

func(to_bool(flags & INTERESTING_FLAG)); 

Otra alternativa podría ser la de definir su tipo booleano ser un intmax_t (de stdint.h), de modo que es imposible para que un valor sea truncado en falsedad

Mientras estoy aquí, quiero decir que usted debe utilizar un typedef para la definición de un nuevo tipo, no un #define:

typedef short Bool; // or whatever type you end up choosing 

Algunos podrían argumentar que se debe utilizar una variable en lugar de const una macro para las constantes numéricas:

const INTERESTING_FLAG = 0x80000000; 

en general hay mejores cosas que puede gastar su tiempo en. Pero macros para typedef s es un poco tonto.

Answer 7

Algunas personas no les gusta, pero yo uso !!.

es decir

!!(flags & CONST_FLAG) 

(no como una macro to_bool como alguien sugirió, sólo directamente en el código).

Si más personas lo usaran, no sería visto como inusual así que empiece a usarlo !!

Answer 8

¿Tiene algo en contra de

flags & INTERESTING_FLAG ? TRUE : FALSE 

?

Answer 9

Esta es la razón por la que solo debe usar los valores de una manera "booleana" cuando estos valores tienen una semántica booleana explícita. Su valor no satisface la regla, ya que tiene una semántica de entero pronunciada (o, más precisamente, semántica de matriz de bits). Con el fin de convertir dicho valor booleano, compararlo con 0

func((flags & INTERESTING_FLAG) != 0);