Warum wird der ternäre Operator verwendet, um 1 und 0 in einem Makro zu definieren?

Ich verwende ein SDK für ein eingebettetes Projekt. In diesem Quellcode habe ich Code gefunden, den ich zumindest merkwürdig fand. An vielen Stellen im SDK gibt es Quellcode in diesem Format:

#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 )

Macht die Verwendung des ternären Operators hier einen Unterschied?

Ist nicht

#define FOO (1 > 0)

das Gleiche wie

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

?

Ich habe versucht, es mit auszuwerten

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

und erhalten das Ergebnis 1, also scheinen sie gleich zu sein. Gibt es einen Grund, den Code so zu schreiben, wie sie es getan haben?

Sie haben Recht, in C ist es tautolog. Sowohl Ihre besondere ternäre Bedingung und (1 > 0) sind vom Typ int.

Aber es möchten in C++ jedoch in einigen merkwürdigen Eckfällen (z. B. als Parameter für überladene Funktionen) von Bedeutung, da Ihr ternärer bedingter Ausdruck vom Typ ist intwohingegen (1 > 0) ist vom Typ bool.

Ich vermute, dass der Autor sich darüber Gedanken gemacht hat, um die C++-Kompatibilität zu erhalten.

Es gibt Linting-Tools, die der Meinung sind, dass das Ergebnis eines Vergleichs boolesch ist und nicht direkt in der Arithmetik verwendet werden kann.

Keine Namen zu nennen oder mit dem Finger zu zeigen, aber PC-Lint ist so ein Fusselwerkzeug.

Ich sage nicht, dass sie Recht haben, aber es ist eine mögliche Erklärung dafür, warum der Code so geschrieben wurde.

Sie werden dies manchmal in sehen sehr alt Code, bevor es einen C-Standard gab, um das zu buchstabieren (x > y) wird als Zahl 1 oder 0 ausgewertet; Einige CPUs würden dies lieber auf -1 oder 0 auswerten lassen, und einige sehr alt Compiler sind vielleicht einfach mitgekommen, daher hatten einige Programmierer das Gefühl, dass sie die zusätzliche Abwehr benötigen.

Sie werden dies manchmal auch sehen, weil ähnlich Ausdrücke nicht unbedingt als Zahl 1 oder 0 auswerten. Zum Beispiel in

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

das Innere &-Ausdruck ergibt entweder 0 oder den numerischen Wert von F_DO_GRENFELZwas wahrscheinlich ist nicht 1, also die ? 1 : 0 dient der Kanonisierung. Ich persönlich denke, es ist klarer, das als zu schreiben

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

aber vernünftige Menschen können anderer Meinung sein. Wenn Sie eine ganze Reihe davon hintereinander hätten und verschiedene Arten von Ausdrücken testen würden, hätte jemand vielleicht entschieden, dass es pflegeleichter ist, sie zu setzen ? 1 : 0 am Ende von alle von ihnen, als sich Gedanken darüber zu machen, welche es tatsächlich brauchten.

Es gibt einen Fehler im SDK-Code, und der Dreier war wahrscheinlich ein Knüppel, um ihn zu beheben.

Da es sich um ein Makro handelt, können die Argumente (alpha_char) beliebige Ausdrücke sein und sollten in Klammern gesetzt werden, da Ausdrücke wie ‘A’ && ‘c’ den Test nicht bestehen.

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

Deshalb sollte man Makroargumente in der Erweiterung immer in Klammern setzen.

In Ihrem Beispiel (aber mit Parametern) sind beide fehlerhaft.

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

Sie würden am besten durch ersetzt werden

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

@CiaPan macht einen wichtigen Punkt im folgenden Kommentar, nämlich dass die mehr als einmalige Verwendung eines Parameters zu undefinierbaren Ergebnissen führt. Zum Beispiel

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

In C spielt es keine Rolle. Boolesche Ausdrücke in C haben Typ int und ein Wert, der entweder ist 0 oder 1Also

ConditionalExpr ? 1 : 0

hat keine Wirkung.

In C++ ist es praktisch eine Umwandlung in intda bedingte Ausdrücke in C++ einen Typ haben 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
*/

}

Es ist auch möglich, dass kein Effekt beabsichtigt war und der Autor einfach dachte, dass es den Code klarer macht.

Eine einfache Erklärung ist, dass einige Leute entweder nicht verstehen, dass eine Bedingung denselben Wert in C zurückgeben würde, oder dass sie denken, dass es sauberer zu schreiben ist ((a>b)?1:0).

Das erklärt, warum einige ähnliche Konstrukte auch in Sprachen mit richtigen Booleschen Werten verwenden, was in C-Syntax der Fall wäre (a>b)?true:false).

Dies erklärt auch, warum Sie dieses Makro nicht unnötig ändern sollten.

Vielleicht würde es als eingebettete Software einige Hinweise geben. Vielleicht gibt es viele Makros, die in diesem Stil geschrieben wurden, um leicht darauf hinzuweisen, dass ACTI-Zeilen direkte Logik anstelle von invertierter Logik verwenden.