Я использую 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, так что кажется, что они равны. Есть ли причина писать код, как они?
Вы правы, в C он тавтологичен. Оба ваших тернарных условных выражения и (1 > 0) имеют тип int.
Но это имело бы значение в С++, хотя в некоторых любопытных случаях (например, в качестве параметров для перегруженных функций), поскольку ваше тернарное условное выражение имеет тип int, тогда как (1 > 0) имеет тип bool.
Мое предположение заключается в том, что автор задумался над этим, имея в виду сохранение совместимости с С++.
Есть инструменты для переливания, которые считают, что результат сравнения является логическим и не может использоваться непосредственно в арифметике.
Не называть имена и не указывать пальцы, но 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 есть ошибка, и троярь, вероятно, был kludge, чтобы исправить его.
Будучи макросом, аргументы (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
не имеет эффекта.
В С++ он эффективно применяется к int, потому что условные выражения в С++ имеют тип 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
*/
}
Также возможно, что никакого эффекта не было, и автор просто подумал, что он сделал код более понятным.
Одно простое объяснение состоит в том, что некоторые люди либо не понимают, что условие возвратит одно и то же значение в C, либо они считают, что писать ((a>b)?1:0) чище.
Это объясняет, почему некоторые из них также используют аналогичные конструкции на языках с правильными логическими значениями, которые в C-синтаксисе будут (a>b)?true:false).
Это также объясняет, почему вы не должны без необходимости менять этот макрос.
Возможно, будучи встроенным программным обеспечением, вы получите некоторые подсказки. Возможно, есть много макросов, написанных с использованием этого стиля, чтобы легко намекнуть, что линии ACTI используют прямую логику, а не инвертированную логику.