Используя истину и ложь в C

Я не знаю вашей конкретной ситуации. Когда я писал программы на C, мы всегда использовали №2.

#define FALSE = 0
#define TRUE = !FALSE

В противном случае это могло быть на чужой платформе для процессоров на базе DOS или Intel. Но раньше я использовал и C, и ASM вместе, создавая графические библиотеки и графическую IDE. Я был настоящим поклонником Майкла Абраша и намеревался узнать о наложении текстур и так далее. В любом случае! Вопрос не в этом!

Это была наиболее часто используемая форма для определения логических значений в C, так как этот заголовочный файл stdbool.h тогда еще не существовал.

Нет, необходимо использовать CGFloat.

При использовании stdbool.h определенного типа bool возникают проблемы при перемещении кода из более нового компилятора, поддерживающего тип bool, в более старый компилятор. Это может произойти во встроенной среде программирования, когда вы переходите к новой архитектуре с компилятором Си на основе более старой версии спецификации.

В суммировании, я бы придерживался макросов, когда портативность имеет значение. В противном случае делайте то, что другие рекомендуют, и используйте bulit in type.

Раньше я использовал # define, потому что они облегчают чтение кода, и не должно быть ухудшения производительности по сравнению с использованием чисел (0,1) coz 'препроцессор преобразует # define в числа перед компиляцией. После запуска приложения препроцессор не вступает в путь снова, потому что код уже скомпилирован.

BTW это должно быть:

#define FALSE 0 
#define TRUE 1

и помните, что -1, -2,... 2, 3 и т.д. все вычисляются как true.

Я предпочитаю третье решение, т. Е. Использование 1 и 0, потому что оно особенно полезно, когда вам нужно проверить, является ли условие истинным или ложным: вы можете просто используйте переменную в качестве аргумента if.
Если вы используете другие методы, я думаю, что для согласованности с остальным кодом мне следует использовать такой тест:

if (variable == TRUE)
{
   ...
}

вместо:

if (variable)
{
   ...
}

Я бы выбрал 1. Я не встречал несовместимости с ним и он более естественен. Но, я думаю, что это часть стандарта C++, а не C. Я думаю, что грязный хакинг с defines или ваш третий вариант - не дадут никакого прироста производительности, а только боль при сопровождении кода.

1 наиболее читаемый, не совместим со всеми компиляторами.

Ни один компилятор ISO C не имеет встроенного типа с именем bool . Компиляторы ISO C99 имеют тип _Bool и заголовок, который typedef имеет bool . Таким образом, совместимость - это просто случай предоставления собственного заголовка, если компилятор не совместим с C99 (например, VC ++).

Конечно, более простой подход - это скомпилировать ваш код C как C ++.

Нет реальной разницы в скорости. Для компилятора они действительно одинаковы. Разница в том, что люди пытаются использовать и читать ваш код.

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

Любое другое чем ноль верно; false равно нулю. Таким образом, подобный код продолжает работать, как ожидалось:

int done = 0;   // `int` could be `bool` just as well

while (!done)
{
     // ...
     done = OS_SUCCESS_CODE == some_system_call ();
}

IMO, bool - это переоцененный тип, возможно, перенесенный из других языков. int отлично работает как логический тип.

Просто используйте 0 или 1 непосредственно в коде.

Для программистов на C это так же интуитивно понятно, как true или false.

Я обычно делаю:

typedef enum {FALSE = 0, TRUE} boolean;

Вы можете проверить, определен ли bool в c99 stdbool.h с помощью

#ifndef __bool_true_false_are_defined || __bool_true_false_are_defined == 0
//typedef or define here
#endif

этот имеет динамическую «область». Это означает, что он настроен любым способом, который его связывает, и этот связан «вызовом метода». То есть в любое время в вашей программе вы видите следующее: w.f () , то пока выполняется f , этот динамически привязан к f , даже , если f имел это в своей лексической области.

Большинство рамок JavaScript предоставляют некоторые объекты для решения этой проблемы. С помощью Prototype.js (например) можно сделать следующее:

this.doSomething(function() { this.doSomethingElse(); }.bind(this));

Ваш «взлом», однако, в порядке. Обычно я делаю (функция (self) {...}) (это) вокруг любых функций, которые мне нужны лексически эта -образная переменная.

Нет, необходимо использовать CGFloat.

При использовании stdbool.h определенного типа bool возникают проблемы при перемещении кода из более нового компилятора, поддерживающего тип bool, в более старый компилятор. Это может произойти во встроенной среде программирования при переходе на новую архитектуру с компилятором Си, основанным на более старой версии спецификации.

В суммировании я бы придерживался макросов, когда важна переносимость. В противном случае делайте то, что другие рекомендуют, и используйте bulit in type.

Я предпочитаю (1), когда определяю переменную, но в выражениях я никогда не сравниваю true и false, просто беру неявное определение на языке Си if(flag) или if(!flag) или if(ptr). Это способ Си делать вещи.