Почему 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 тип. Для этой цели можно использовать байты и даже биты. Другими словами,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.