¿Por qué se usa el operador ternario para definir 1 y 0 en una macro?

Estoy usando un SDK para un proyecto integrado. En este código fuente encontré un código que al menos me pareció peculiar. En muchos lugares del SDK hay un código fuente en este formato:

#define ATCI_IS_LOWER( alpha_char )  ( ( (alpha_char >= ATCI_char_a) && (alpha_char <= ATCI_char_z) ) ? 1 : 0 )

#define ATCI_IS_UPPER( alpha_char )  ( ( (alpha_char >= ATCI_CHAR_A) && (alpha_char <= ATCI_CHAR_Z) ) ? 1 : 0 )

¿El uso del operador ternario aquí hace alguna diferencia?

No es

#define FOO (1 > 0)

lo mismo que

#define BAR ( (1 > 0) ? 1 : 0)

?

Intenté evaluarlo usando

printf("%d", FOO == BAR);

y obtiene el resultado 1, por lo que parece que son iguales. ¿Hay alguna razón para escribir el código como lo hicieron?

Tienes razón, en C es tautólogo. Tanto su ternaria en particular condicional y (1 > 0) son de tipo int.

Pero sería importante en C ++, sin embargo, en algunos casos curiosos (por ejemplo, como parámetros para funciones sobrecargadas), ya que su expresión condicional ternaria es de tipo int, mientras que (1 > 0)es de tipo bool.

Supongo que el autor ha pensado un poco en esto, con miras a preservar la compatibilidad con C ++.

Hay herramientas de linting que opinan que el resultado de una comparación es booleano y no se puede usar directamente en aritmética.

No es para nombrar nombres o señalar con el dedo, pero PC-lint es una herramienta muy interesante .

No digo que tengan razón, pero es una posible explicación de por qué el código se escribió así.

A veces verá esto en un código muy antiguo , de antes de que existiera un estándar C para deletrear que se (x > y)evalúa como 1 o 0 numérico; algunas CPU prefieren hacer que la evaluación sea -1 o 0 en su lugar, y algunos compiladores muy antiguos pueden haberlo seguido, por lo que algunos programadores sintieron que necesitaban una actitud defensiva adicional.

A veces también verá esto porque expresiones similares no necesariamente se evalúan como 1 o 0 numérico. Por ejemplo, en

#define GRENFELZ_P(flags) (((flags) & F_DO_GRENFELZ) ? 1 : 0)

la &expresión interna se evalúa como 0 o el valor numérico de F_DO_GRENFELZ, que probablemente no es 1, por lo que ? 1 : 0sirve para canonicalizarlo. Personalmente, creo que es más claro escribir eso como

#define GRENFELZ_P(flags) (((flags) & F_DO_GRENFELZ) != 0)

pero la gente razonable puede estar en desacuerdo. Si tuviera un montón de estos en una fila, probando diferentes tipos de expresiones, alguien podría haber decidido que era más fácil de mantener al ? 1 : 0final de todos ellos que preocuparse por cuáles realmente lo necesitaban.

Hay un error en el código del SDK, y el ternario probablemente fue una torpeza para solucionarlo.

Al ser una macro, los argumentos (alpha_char) pueden ser cualquier expresión y deben estar entre paréntesis porque expresiones como 'A' && 'c' fallarán la prueba.

#define IS_LOWER( x ) ( ( (x >= 'a') && (x <= 'z') ) ?  1 : 0 )
std::cout << IS_LOWER('A' && 'c');
**1**
std::cout << IS_LOWER('c' && 'A');
**0**

Es por eso que siempre se deben poner entre paréntesis los argumentos macro en la expansión.

Entonces, en su ejemplo (pero con parámetros), ambos tienen errores.

#define FOO(x) (x > 0)
#define BAR(x) ((x > 0) ? 1 : 0)

Serían reemplazados más correctamente por

#define BIM(x) ((x) > 0)

@CiaPan Hace un gran punto en el siguiente comentario, que es que usar un parámetro más de una vez conduce a resultados indefinibles. Por ejemplo

#define IS_LOWER( x ) (((x) >= 'a') && ((x) <= 'z'))
char ch = 'y';
std::cout << IS_LOWER(ch++);
**1** 
**BUT ch is now '{'**

En C no importa. Las expresiones booleanas en C tienen un tipo inty un valor que es 0o 1, entonces

ConditionalExpr ? 1 : 0

no tiene efecto.

En C ++, es efectivamente una conversión a int, porque las expresiones condicionales en C ++ tienen tipo bool.

#include <stdio.h>
#include <stdbool.h>

#ifndef __cplusplus

#define print_type(X) _Generic(X, int: puts("int"), bool: puts("bool") );

#else
template<class T>
int print_type(T const& x);
template<> int print_type<>(int const& x) { return puts("int"); }
template<> int print_type<>(bool const& x) { return puts("bool"); }


#endif

int main()
{
    print_type(1);
    print_type(1 > 0);
    print_type(1 > 0 ? 1 : 0);

/*c++ output:
  int 
  int 
  int

  cc output:
  int
  bool
  int
*/

}

También es posible que no se pretendiera ningún efecto, y el autor simplemente pensó que aclaraba el código.

Una explicación simple es que algunas personas no comprenden que una condición devolvería el mismo valor en C o piensan que es más limpio escribir ((a>b)?1:0).

Eso explica por qué algunos también usan construcciones similares en lenguajes con booleanos adecuados, que en la sintaxis C sería (a>b)?true:false).

Esto también explica por qué no debería cambiar innecesariamente esta macro.

Quizás, al ser un software integrado, daría algunas pistas. Tal vez haya muchas macros escritas con este estilo, para indicar fácilmente que las líneas ACTI usan lógica directa en lugar de lógica invertida.