Чому тернарний оператор використовується для визначення 1 і 0 у макросі?

Я використовую SDK для вбудованого проекту. У цьому вихідному коді я знайшов якийсь код, який, принаймні, мені здався своєрідним. У багатьох місцях SDK є вихідний код у такому форматі:

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

Чи має значення використання трійкового оператора тут якусь різницю?

Ні

#define FOO (1 > 0)

такий же як і

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

?

Я спробував оцінити це за допомогою

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

і отримати результат 1, тож здається, що вони рівні. Чи є причина писати код так, як вони це робили?

Ви праві, в С це тавтологічно. Як ваш конкретний трійковий умовний, так і (1 > 0) тип int.

Але це мало б значення в C ++, в деяких цікавих кутових випадках (наприклад, як параметри для перевантажених функцій), оскільки ваш трійковий умовний вираз має тип int, тоді як (1 > 0)- тип bool.

Я здогадуюсь, що автор задумався над цим, намагаючись зберегти сумісність C ++.

Існують інструменти зв’язування, які вважають, що результат порівняння є логічним і не може використовуватися безпосередньо в арифметиці.

Не називати імена та вказувати пальцями, але PC-lint - це такий інструмент для обшивки .

Я не кажу, що вони мають рацію, але це можливе пояснення, чому код був написаний саме так.

Іноді ви побачите це у дуже старому коді, ще до того, як існував стандарт C, який визначається (x > y)як числовий 1 або 0; деякі центральні процесори воліють зробити замість цього значення -1 або 0, а деякі дуже старі компілятори, можливо, просто підписалися, тому деякі програмісти відчували, що їм потрібна додаткова захист.

Ви іноді це також побачите, оскільки подібні вирази не обов’язково мають бути числом 1 або 0. Наприклад, у

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

внутрішній &-вираз виражається або 0, або числовим значенням F_DO_GRENFELZ, яке, ймовірно, не 1, тому ? 1 : 0служить для його канонізації. Я особисто думаю, що зрозуміліше писати це як

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

але розумні люди можуть не погодитися. Якби у вас була ціла купа таких поспіль, тестуючи різні типи виразів, хтось міг би вирішити, що було б більш рентабельним поставити ? 1 : 0кінець на всіх, ніж турбуватися про те , кому з них це насправді потрібно.

У коді SDK є помилка, і тернар, мабуть, був ключем для її виправлення.

Будучи макросом, аргументи (alpha_char) можуть бути будь-якими виразами і повинні бути в дужках, оскільки вирази, такі як 'A' && 'c', не пройдуть перевірку.

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

Ось чому в розширенні завжди слід вводити аргументи макросів у дужки.

Отже, у вашому прикладі (але з параметрами) вони обидва помилкові.

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

Їх найбільш коректно замінили б на

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

@CiaPan робить чудовий момент у наступному коментарі, який полягає в тому, що використання параметра більше одного разу призводить до невизначених результатів. Наприклад

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

У C це не має значення. Логічні вирази на мові C мають тип intі значення або 0або 1, так

ConditionalExpr ? 1 : 0

не має ефекту.

У C ++ це фактично приклад int, оскільки умовні вирази в C ++ мають тип 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
*/

}

Можливо, також не передбачався ефект, і автор просто подумав, що це зробило код чіткішим.

Одне з простих пояснень полягає в тому, що деякі люди або не розуміють, що умова поверне одне і те ж значення в С, або вони вважають, що це чистіше писати ((a>b)?1:0).

Це пояснює, чому деякі також використовують подібні конструкції в мовах з належними булевими значеннями, що було б у C-синтаксисі (a>b)?true:false).

Це також пояснює, чому вам не слід без потреби змінювати цей макрос.

Можливо, будучи вбудованим програмним забезпеченням, це може дати деякі підказки. Можливо, існує багато макросів, написаних із використанням цього стилю, щоб легко натякнути, що рядки ACTI використовують пряму логіку, а не інвертовану логіку.