Когда BOOL и bool должны использоваться в C ++?

Question

Когда следует использовать BOOL и bool в C ++ и почему?

Я думаю, что использование bool чище и более портативно, потому что это встроенный тип. Но BOOL неизбежен, когда вы взаимодействуете с унаследованным кодом / кодом C или выполняете взаимодействие из .NET с кодом C / Windows API.

Итак, моя политика такова: Используйте bool внутри C ++. Используйте BOOL при общении с внешним миром, например, функцию экспорта в Windows DLL.

Есть ли однозначное объяснение того, когда использовать один над другим?

Answer 1

Если BOOL является своего рода целочисленным типом, и это всегда так, и BOOL определен так, чтобы он работал правильно, стандартные преобразования автоматически получат его правильно. Вы не можете использовать их взаимозаменяемо, но вы можете приблизиться.

Используйте BOOL на интерфейсе, где вам нужно поговорить с Win32 API или чем-то еще. Используйте bool везде.

Answer 2

Мэтью Уилсон обсуждает BOOL, bool и аналогичные в разделе 13.4.2 Несовершенный C ++ . Смешивание этих двух может быть проблематичным, поскольку они обычно имеют разные размеры (и поэтому указатели и ссылки не являются взаимозаменяемыми), и поскольку bool не гарантирует какого-либо определенного размера. Попытка использовать typedefs или условную компиляцию для сглаживания различий между BOOL и bool или попытка разрешить одному булевому типу работать как на C, так и на C ++ еще хуже:

#if defined(__cplusplus) || \
    defined(bool) /* for C compilation with C99 bool (macro) */
 typedef bool   bool_t;
#else
 typedef BOOL   bool_t;
#endif /* __cplusplus */

Этот подход означает, что тип возвращаемого значения функции может различаться в зависимости от того, какой язык ее вызывает; Уилсон объясняет, что он видел более одной ошибки в своем собственном коде и других, что вытекает из этого. Он приходит к выводу:

Решением этого недостатка, как это часто бывает, является воздержание. Я никогда не использую bool для чего-либо, что может быть доступно через несколько блоков ссылок - динамические / статические библиотеки, поставляемые объектные файлы - что в основном означает не в функциях или классах, которые появляются вне заголовочных файлов. Практический ответ, как он есть, заключается в использовании псевдобулева типа, который имеет размер int.

Короче, он согласился бы с вашим подходом.

Answer 3

Видимо, нет веских оснований для использования BOOL:

http://blogs.msdn.com/oldnewthing/archive/2008/03/25/8334558.aspx
http://blogs.msdn.com/oldnewthing/archive/2004/12/22/329884.aspx

Answer 4

Другая ситуация, когда вы должны использовать BOOL: при реализации функции обратного вызова, которая принимает или возвращает BOOL.

Например, EnumWindows() получает указатель на функцию обратного вызова со следующей подписью:

BOOL CALLBACK EnumWindowsProc(      
    HWND hwnd,
    LPARAM lParam
);

Если вы используете для этого bool, вам придется типизировать указатель на функцию.

Answer 5

Если вы хотите использовать функцию, написанную на C ++ (например, встроенную в библиотеку DLL), в управляемой программе (например, в C #), у вас есть для использования BOOL. Если вы вернете bool, результат всегда будет верным - это известная ошибка в течение длительного времени и, видимо, еще не решенная (VS 2010, .NET Framework 4).

С наилучшими пожеланиями - Spook.

Answer 6

Я думаю о «true» / «TRUE» и «false» / ​​«FALSE» как о синтаксическом сахаре, решении проблемы, которой никогда не было. Я всегда думал, что проще использовать и читать «1» и «0».

Когда вы думаете о включении или выключении флагов в регистрах, думаете ли вы об 1 или 0 или об истинах и ложных значениях? Что произойдет, если вы захотите сохранить несколько флагов в одной переменной? 1 и 0 универсальны.

Я думаю, что слово "ложь" слишком длинное для своего блага. Когда я вижу «0», он выделяется в моей голове как красный знак остановки. Стоп-знаки красного цвета, потому что красный цвет привлекает внимание людей. Читать слово «ложь» - это все равно, что видеть зеленый знак остановки.

Итак, к черту bool и BOOL. Я по умолчанию int.

... но, действительно, правильные логические флаги - это наименьшее беспокойство в языке с таким количеством способов ошибиться, как C ++.