Самая большая проблема в том, что нет указателя на «упакованный бул» - как если бы у вас был int32, который упаковывает 32 логических значения, то вы не можете сделать bool* или bool&, который ссылается на любой из них надлежащим образом. Это связано с тем, что байт является минимальной единицей памяти.
В STL они сделали std::vector<bool>, что сэкономило место и имело семантически тот же интерфейс, что и другие векторы. Для этого им нужно было создать специальный прокси-класс, который возвращается из operator [], поэтому нужно делать что-то вроде boolVec[5] = true. К сожалению, это чрезмерное усложнение привело ко многим проблемам с производительностью и использованием std::vector<bool>.
. Даже простые инструкции для упакованных логических значений имеют тенденцию быть составными и, следовательно, более тяжелыми, чем если бы логические значения представляли через bool и принимали целый байт. Кроме того, изменение значений упакованного логического значения может вызывать скачки данных в многопоточной среде.
По сути, аппаратное обеспечение просто не слишком хорошо поддерживает логические значения.
Далее, изображение POV ОС конструктор, и вы создаете общий интерфейс общих библиотек (он же dll). Как лечить булевы сейчас? Байт - это минимальный блок памяти, поэтому для передачи одного логического значения все равно потребуется использовать хотя бы один байт. Так почему бы просто не забыть о существовании bool и просто передать его одним байтом? Поэтому нам даже не нужно реализовывать этот ненужный тип bool, и это сэкономит много времени для всех авторов компиляторов всех языков.
uint8 vs uint32; Также обратите внимание, что Windows 'COM (объектная модель компонента - не последовательный порт) использует int16 для логического значения. В общем, это по сути неважно, так как при передаче значений в функцию совместно используемой библиотеки, которая выполняет сложные задачи, не будет иметь заметного различия в производительности, поскольку вы уже вызываете гораздо более тяжелую функцию. Тем не менее, почему это так? Я предполагаю, что у них были некоторые причины долгое время go, когда они проектировали его, и все уже забыли почему, и они просто оставляют это без изменений, поскольку изменение этого приведет к полной катастрофе с точки зрения обратной совместимости.
В C99 _Bool был представлен для логических значений, но это просто другое имя для неподписанного целого. Я представляю себе из этого возникшего использования uint32 для логических значений. В целом, int, предположительно, является наиболее эффективным целочисленным типом с точки зрения производительности (который поэтому не имеет строго определенного размера), поэтому комитет C выбрал предположительно наиболее эффективный тип для представления логических значений.