Почему #define TRUE (1==1) в логическом макросе C, а не просто как 1?

Этот подход будет использовать фактический тип boolean (и разрешать в true и false), если компилятор его поддерживает. (в частности, С++)

Однако было бы лучше проверить, используется ли C++ (с помощью макроса __cplusplus), и действительно использовать true и false.

В компиляторе C это эквивалентно 0 и 1.
(обратите внимание, что удаление круглых скобок нарушит это из-за порядка операций)

Ответ — переносимость. Числовые значения TRUE и FALSE не важны. Что важно, так это то, что оператор типа if (1 < 2) оценивается как if (TRUE), а оператор типа if (1 > 2) оценивается как if (FALSE).

Конечно, в C (1 < 2) оценивается как 1, а (1 > 2) оценивается как 0, поэтому, как говорили другие, с точки зрения компилятора нет никакой практической разницы. Но позволяя компилятору определять TRUE и FALSE в соответствии с его собственными правилами, вы делаете их значения явными для программистов и гарантируете согласованность в вашей программе и любой другой библиотеке (при условии, что другая библиотека соответствует стандартам C... вы был бы поражен).

Немного истории
Некоторые BASIC определяют FALSE как 0, а TRUE как -1. Как и многие современные языки, они интерпретировали любое ненулевое значение как TRUE, но оценивали логические выражения, которые были истинными, как -1. Их операция NOT была реализована путем добавления 1 и перестановки знака, потому что это было эффективно. Таким образом, «НЕ x» стало -(x+1). Побочным эффектом этого является то, что значение, подобное 5, оценивается как TRUE, а NOT 5 оценивается как -6, что также равно TRUE! Найти такой баг не весело.

Рекомендации
Учитывая правила де-факто, согласно которым ноль интерпретируется как FALSE, а любое ненулевое значение интерпретируется как TRUE, вам следует никогда не сравнивайте логические выражения с TRUE или FALSE. Примеры:

if (thisValue == FALSE)  // Don't do this!
if (thatValue == TRUE)   // Or this!
if (otherValue != TRUE)  // Whatever you do, don't do this!

Почему? Потому что многие программисты используют ярлык обработки ints как bools. Они не совпадают, но компиляторы обычно это допускают. Так, например, совершенно законно писать

if (strcmp(yourString, myString) == TRUE)  // Wrong!!!

Это выглядит законно, и компилятор с радостью это примет, но, вероятно, это не то, что вам нужно. Это потому, что возвращаемое значение strcmp() равно

0, если yourString == myString
‹0, если yourString < myString
>0, если yourString > myString

Таким образом, строка выше возвращает TRUE только тогда, когда yourString > myString.

Правильный способ сделать это либо

// Valid, but still treats int as bool.
if (strcmp(yourString, myString))

or

// Better: lingustically clear, compiler will optimize.
if (strcmp(yourString, myString) != 0)

Так же:

if (someBoolValue == FALSE)     // Redundant.
if (!someBoolValue)             // Better.
return (x > 0) ? TRUE : FALSE;  // You're fired.
return (x > 0);                 // Simpler, clearer, correct.
if (ptr == NULL)                // Perfect: compares pointers.
if (!ptr)                       // Sleazy, but short and valid.
if (ptr == FALSE)               // Whatisthisidonteven.

Вы часто будете находить некоторые из этих «плохих примеров» в производственном коде, и многие опытные программисты клянутся ими: они работают, некоторые короче, чем их (педантично?) правильные альтернативы, а идиомы почти общепризнанны. Но учтите: «правильные» версии не менее эффективны, они гарантированно переносимы, они пройдут даже самые строгие линтеры, и их поймут даже начинающие программисты.

Разве это того не стоит?

Трюк с (1 == 1) полезен для определения TRUE способом, прозрачным для C, но обеспечивающим лучшую типизацию в C++. Один и тот же код может быть интерпретирован как C или C++, если вы пишете на диалекте под названием «Чистый C» (который компилируется как C или C++) или если вы пишете заголовочные файлы API, которые могут использоваться программистами C или C++.

В единицах перевода C 1 == 1 имеет точно такое же значение, как 1; и 1 == 0 имеет то же значение, что и 0. Однако в единицах перевода C++ 1 == 1 имеет тип bool. Поэтому макрос TRUE, определенный таким образом, лучше интегрируется в C++.

Примером лучшей интеграции является то, что, например, если функция foo имеет перегрузки для int и для bool, то foo(TRUE) выберет перегрузку bool. Если TRUE просто определено как 1, то это не будет хорошо работать в C++. foo(TRUE) захочет перегрузку int.

Конечно, C99 представил bool, true и false, и их можно использовать в файлах заголовков, которые работают с C99 и с C.

Тем не мение:

• эта практика определения TRUE и FALSE как (0==0) и (1==0) предшествовала C99.
• все еще есть веские причины держаться подальше от C99 и работать с C90.

Если вы работаете в смешанном проекте C и C++ и не хотите использовать C99, вместо этого определите строчные буквы true, false и bool.

#ifndef __cplusplus
typedef int bool;
#define true (0==0)
#define false (!true)
#endif

При этом трюк 0==0 использовался (используется?) некоторыми программистами даже в коде, который никогда не предназначался для взаимодействия с C++ каким-либо образом. Это ничего не покупает и предполагает, что программист неправильно понимает, как логические значения работают в C.

В случае, если объяснение C++ не было ясным, вот тестовая программа:

#include <cstdio>

void foo(bool x)
{
   std::puts("bool");  
}

void foo(int x)
{
   std::puts("int");  
}

int main()
{
   foo(1 == 1);
   foo(1);
   return 0;
}

Выход:

bool
int

Что касается вопроса из комментариев о том, как перегружаются функции C++, относящиеся к смешанному программированию на C и C++. Они просто иллюстрируют разницу типов. Веская причина для того, чтобы константа true была bool при компиляции как C++, - это чистая диагностика. На самых высоких уровнях предупреждений компилятор C++ может предупредить нас о преобразовании, если мы передаем целое число в качестве параметра bool. Одной из причин написания на чистом C является не только то, что наш код более переносим (поскольку его понимают компиляторы C++, а не только компиляторы C), но и то, что мы можем извлечь пользу из диагностических мнений компиляторов C++.