forcing value to bool 'true' or 'false' - C/C++

Есть функция

function foo(bool r)  {...}

Вызывается в том числе и так:

#define TRUE 1
...
foo(TRUE);

При компиляции генерируется грустное сообщение:

warning C4800: 'BOOL' : forcing value to bool 'true' or 'false' (performance warning)

Лечится

foo(onoff != FALSE);

но смысла в том не вижу вообще. Неужели вот это последнее более эффективно чем просто приведение к bool?

CS>но смысла в том не вижу вообще. Неужели вот это последнее более эффективно чем просто приведение к bool?

нет, ни капли не эффективнее

Здравствуйте, c-smile, Вы писали:

CS>

CS>warning C4800: 'BOOL' : forcing value to bool 'true' or 'false' (performance warning)

А BOOL тут откуда взялся ? Это не WIN API программа часом ? Если да,то там свой TRUE есть, и именно типа BOOL

Здравствуйте, c-smile, Вы писали:

CS>foo(onoff != FALSE);

CS>но смысла в том не вижу вообще. Неужели вот это последнее более эффективно чем просто приведение к bool?

Ворнинг говорит о том, что операция "foo != FALSE" будет неявно сделана. Если сделать её явной, смысл в ворнинге отпадает, т.к. она явно видна в коде.

"Более эффективным" же будет использование везде только BOOL, либо только bool, таким образом можно было бы избежать эту "лишнюю" проверку.

Здравствуйте, c-smile, Вы писали:

CS>Есть функция

CS>

CS>function foo(bool r)  {...}
CS>

CS>Вызывается в том числе и так:

CS>

CS>#define TRUE 1
CS>...
CS>foo(TRUE); 
CS>

CS>При компиляции генерируется грустное сообщение:

CS>

CS>warning C4800: 'BOOL' : forcing value to bool 'true' or 'false' (performance warning)

CS>Лечится

CS>

CS>foo(onoff != FALSE); 
CS>

CS>но смысла в том не вижу вообще. Неужели вот это последнее более эффективно чем просто приведение к bool?

В данном случае, поскольку у тебя константа, никакой потери производительности не будет.
А вообще -- выключи этот warning, да и всё. Не все warning и одинаково полезны.

а нельзя просто

foo(true)

дергать?

если хочется запихивать BOOL -- то и параметр таким сделать. Если нужен параметром bool -- так им и пользоваться, честным true/false

Смысл становится очевиден когда оказывается, что привидение к bool
CS>

CS>foo(onoff != FALSE); 
CS>

может в реальности осуществляется 100500 способами, в зависимости от контекста:

foo(TRUE == result);

foo((TRUE == result) || (MAYBE == result));

#define ERROR_SUCCESS 0
foo(ERROR_SUCCESS != result);

foo(0 <= result);

foo(32 < result);

и т.д.

Здравствуйте, c-smile, Вы писали:
CS>

CS>foo(onoff != FALSE); 
CS>

CS>но смысла в том не вижу вообще. Неужели вот это последнее более эффективно чем просто приведение к bool?
foo(!!onoff);

Здравствуйте, IROV.., Вы писали:

IRO>Здравствуйте, c-smile, Вы писали:
CS>>

CS>>foo(onoff != FALSE); 
CS>>

CS>>но смысла в том не вижу вообще. Неужели вот это последнее более эффективно чем просто приведение к bool?
IRO>foo(!!onoff);

Синтаксическая экономия?

Здравствуйте, c-smile, Вы писали:

CS>Лечится

CS>

CS>foo(onoff != FALSE); 
CS>

CS>но смысла в том не вижу вообще. Неужели вот это последнее более эффективно чем просто приведение к bool?

Ничего не поделаешь, тяжелое наследие WinAPI. Ну не было bool когда WinAPI писался (C99?).
Так что да, foo(onoff != FALSE), хоть и тупо. Если хочешь чтобы все компилировалось без предупреждений.
Я думаю с помощью этого предупреждения мелко-мягкие добро насаждали — народ на bool переводили (чтобы он был везде)

Здравствуйте, bnk, Вы писали:

bnk>Ничего не поделаешь, тяжелое наследие WinAPI. Ну не было bool когда WinAPI писался (C99?).
Что именно? Использование TRUE вместо true в С++ коде?

Если же речь про использование int AKA BOOL в качестве bool, то интерпретация int в таком качестве возможна разная, кроме стандартной С-шной (!=0), так что лучше не смешивать, а если уж смешиваешь -- приводить явно.
Например так:

inline bool toBool( BOOL b ) 
{
    assert( b == TRUE || b == FALSE );
    return (bool)b; 
}

bnk>Так что да, foo(onoff != FALSE), хоть и тупо. Если хочешь чтобы все компилировалось без предупреждений.
bnk>Я думаю с помощью этого предупреждения мелко-мягкие добро насаждали — народ на bool переводили (чтобы он был везде)

На самом деле могут быть эффекты всякие нежданные. Скажем (bool)b может брать младший байт, а в b "случайно" окажется 07272720400, например

Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском

Здравствуйте, Erop, Вы писали:

E> Скажем (bool)b может брать младший байт, а в b "случайно" окажется 07272720400, например

Это вряд ли.

A prvalue of arithmetic, unscoped enumeration, pointer, or pointer to member type can be converted to a
prvalue of type bool. A zero value, null pointer value, or null member pointer value is converted to
false; any other value is converted to true.

Здравствуйте, Erop, Вы писали:

E>На самом деле могут быть эффекты всякие нежданные. Скажем (bool)b может брать младший байт, а в b "случайно" окажется 07272720400, например ;)

Не может. Выше уже привели цитату почему. Такая конструкция надёжна, и сравнивает b с нулём.

Но ты прав в том смысле, что компилятор в машинном коде вместо сравнения с нулём может генерировать инструкцию взятия младшего байта (и на самом деле делает так достаточно часто).
Правда тут причина в ином — bool определён по разному в C/C++ и в ABI. То есть при трансляции высокоуровнего кода вида (bool)b будет всегда идти сравнение всего значения b, потому что это описывается стандартом C/C++. После чего полученное значение будет уже подчиняться правилам ABI, где возможны другие варианты. Но это всё уже не про C/C++.
Вот демонстрация: C++/C bool != true и false — компилятор действительно берёт лишь младший байт вместо сравнения с нулём, но из чистого well-defined C/C++ кода такого поведения не достигнуть.

Здравствуйте, Alexander G, Вы писали:

AG>Здравствуйте, Erop, Вы писали:

E>> Скажем (bool)b может брать младший байт, а в b "случайно" окажется 07272720400, например

AG>Это вряд ли.
AG>

AG>A prvalue of arithmetic, unscoped enumeration, pointer, or pointer to member type can be converted to a
AG>prvalue of type bool. A zero value, null pointer value, or null member pointer value is converted to
AG>false; any other value is converted to true.

Это если не reinterpet_cast, например...
Честное неявное преобразование, которое с сравнением дорогое же...

Здравствуйте, watchmaker, Вы писали:

W>Вот демонстрация: C++/C bool != true и false — компилятор действительно берёт лишь младший байт вместо сравнения с нулём, но из чистого well-defined C/C++ кода такого поведения не достигнуть.

Ну я просто поленился reinterpret слово писать. Суть в том, что если преобразовывать как-то быстро, то могут быть штуки, а если надёжно, то не самый быстрый путь... Другое дело, что наверное долго искать пример, когда на эту "небыстроту" нельзя забить

Но суть одна, либо вообще не надо типы мешать, либо преобразовывать явно как-то, например, иметь функции fastToBool и safeToBool

Здравствуйте, T4r4sB, Вы писали:

CS>>>

CS>>>foo(onoff != FALSE); 
CS>>>

CS>>>но смысла в том не вижу вообще. Неужели вот это последнее более эффективно чем просто приведение к bool?
IRO>>foo(!!onoff);
TB>Синтаксическая экономия?

откуда нам знать, что подставится вместо FALSE ?

Здравствуйте, B0FEE664, Вы писали:

BFE>откуда нам знать, что подставится вместо FALSE ?

Ну, если BOOL вин-апишный, то это стандартизировано, кроме того, стандарте С пишут, что всё, что не ноль -- истина, а ноль -- ложь...

Здравствуйте, Erop, Вы писали:

BFE>>откуда нам знать, что подставится вместо FALSE ?
E>Ну, если BOOL вин-апишный, то это стандартизировано, кроме того, стандарте С пишут, что всё, что не ноль -- истина, а ноль -- ложь...

Не виндой единой...
Да и потом, я легко могу себе представить:

#define NULL ((void*)0)
//... same headers later
#define FALSE NULL

Здравствуйте, B0FEE664, Вы писали:

E>>Ну, если BOOL вин-апишный, то это стандартизировано, кроме того, стандарте С пишут, что всё, что не ноль -- истина, а ноль -- ложь...

BFE>Да и потом, я легко могу себе представить:

BFE>

BFE>#define NULL ((void*)0)
BFE>//... same headers later
BFE>#define FALSE NULL
BFE>

Так это всё равно 0...

Здравствуйте, Erop, Вы писали:

E>>>Ну, если BOOL вин-апишный, то это стандартизировано, кроме того, стандарте С пишут, что всё, что не ноль -- истина, а ноль -- ложь...

BFE>>Да и потом, я легко могу себе представить:

BFE>>

BFE>>#define NULL ((void*)0)
BFE>>//... same headers later
BFE>>#define FALSE NULL
BFE>>

E>Так это всё равно 0...

только вот foo(onoff != FALSE); не скомпилируется, если onoff целого типа

От:	c-smile	http://terrainformatica.com
Дата:	07.12.15 04:24
Оценка:

	От:	watchyourinfo
	Дата:	07.12.15 05:03
	Оценка:

	От:	Pavel Dvorkin
	Дата:	07.12.15 05:31
	Оценка:	+2

	От:	Alexander G
	Дата:	07.12.15 05:58
	Оценка:	+1

	От:	Шахтер
	Дата:	07.12.15 06:42
	Оценка:	+1

От:	K13	http://akvis.com
Дата:	07.12.15 07:07
Оценка:	+3

От:	VTT	http://vtt.to
Дата:	07.12.15 07:55
Оценка:	-1

От:	bnk	http://unmanagedvisio.com/
Дата:	12.12.15 08:38
Оценка:

	От:	IROV..
	Дата:	09.12.15 23:43
	Оценка:	+1 -1

	От:	T4r4sB
	Дата:	10.12.15 08:18
	Оценка:

	От:	Erop
	Дата:	15.12.15 13:27
	Оценка:

	От:	watchmaker
	Дата:	15.12.15 14:02
	Оценка: