Почему WinAPI использует int (32 бита) для типа BOOL?

// <windef.h>

typedef int                 BOOL;

разве это не пустая трата памяти, поскольку int-это 32 бита?

на всякий случай, если я ошибся, я попытался отправить нормальный bool* к функции, которая требовала BOOL* и не работал, пока я не использовал typedef int.

4 ответов


Вау, притормози немного есть. Прежде всего, я уверен, что программисты использовали 4-байтовый ints для булевых переменных с начала программирования на x86. (Раньше не было такой вещи, как bool тип данных). И я рискну предположить,что этот же typedef находится в Windows 3.1 <Windows.h>.

во-вторых, вам нужно понять немного больше об архитектуре. У вас есть 32-разрядная машина, что означает, что все регистры CPU составляют 4 байта или 32 бита широкий. Поэтому для большинства обращений к памяти это более эффективным!--9--> для хранения и доступа к 4-байтовым значениям, чем для 1-байтового значения.

если у вас есть четыре 1-байтовые логические переменные, упакованные в один 4-байтовый кусок памяти, три из них не выровнены по DWORD (4-байт). Это означает, что контроллер CPU / памяти на самом деле должен делать больше работа, чтобы получить значение.

и прежде чем вы идете разбивая на MS для создания этого "расточительного" typedef. Подумайте: под Худ, большинство компиляторов (вероятно) еще реализовать bool тип данных 4 байта int по тем же причинам, о которых я только что упомянул. Попробуйте в gcc и посмотрите на файл карты. Держу пари, я прав.


во-первых, тип, используемый в системном API, должен быть как можно более независимым от языка, потому что этот API будет использоваться множеством языков программирования. По этой причине любые" концептуальные " типы, которые могут либо не существовать на некоторых языках, либо могут быть реализованы по-разному на других языках, не подлежат сомнению. Например, bool вписывается в эту категорию. Кроме того, в системном API очень хорошая идея-свести количество типов интерфейса к минимуму. Все, что может быть представлен int должно быть представлено int.

BOOL элементы. Windows API не использует такие типы данных. Если вы создали такой расточительный тип данных в своей программе, это на самом деле ваша вина. Между тем, Windows API никоим образом не заставляет вас сохраните логические значения в BOOL тип. Для этой цели можно использовать байты и даже биты. Другими словами,BOOL чисто интерфейс тип. Объект BOOLтип обычно не занимают никакой долгосрочной памяти вообще, если вы используете его правильно.

процессор 32 бит, и имеет специальный флаг, когда он работает на нулевое целое число, что делает тестирование для 32-битных логических значений очень, очень, очень быстро.

тестирование на 1 бит или одно байтовое логическое значение будет во много раз медленнее.

Если вы беспокоитесь о пространстве памяти, то вы можете беспокоиться о 4-байтовых переменных bool.

большинство программистов, однако, больше беспокоятся о производительности, и поэтому по умолчанию используется более быстрый 32 бит тип bool.

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


исторически BOOL как ничего-не-0 = истинный тип. Например, процедура диалога возвращает BOOL, это может нести много информации. Подпись ниже от собственная документация Microsoft:

BOOL CALLBACK DlgProc(HWND hwndDlg, UINT message, WPARAM wParam, LPARAM lParam) 

результат подписи и функции объединил несколько вопросов, поэтому в современном API вместо

INT_PTR CALLBACK DialogProc(
    _In_  HWND hwndDlg,
    _In_  UINT uMsg,
    _In_  WPARAM wParam,
    _In_  LPARAM lParam
);

эта новомодная декларация должна оставаться совместимой со старой один. Что означает, что INT_PTR и BOOL должны быть одинакового размера. Это означает, что в 32-разрядном программировании BOOL - это 32 бита.

в общем, с BOOL может быть любое значение, а не только 0 и 1, это очень плохая идея сравнить a BOOL to TRUE. И хотя это работает, чтобы сравнить его с FALSE, это, как правило, также плохая практика, потому что это может легко дать людям впечатление, что сравнение с TRUE было бы хорошо. Кроме того, потому что это довольно ненужный.

кстати, в API Windows больше логических типов, в частности VARIANT_BOOL который равен 16 битам и где логическое TRUE представлено как all 1 bitpattern, т. е. -1 как знаковое значение...

это дополнительная причина, почему не стоит сравнивать напрямую с логическим FALSE или TRUE.