@kostik45030 янв 2012 в 16:04

BOOL или BOOLEAN — вот в чем вопрос?

2 мин

50K

C++ *

-13

Комментарии 76

@Vass 30 янв 2012 в 16:11

Аккаунт угнали?

@kostik450 30 янв 2012 в 18:26

Нет, просто я в очередной раз пишу более-менее нормальную техническую статью, а не обзор очередной версии FF и/или Убунты, как некоторые.

А получаю в ответ от хабравчан кучу минусов в карму, как и за прошлую свою статью, тоже чисто техническую, посвященную 3TB дискам. Вывод очевиден.

@Andrey2008 30 янв 2012 в 18:48

Не обижайтесь, но статья такая. Я знаком с Си++ и сам пишу статьи по программированию. И ставлю минусы обзором FF/Убунты и тому подобному. И плюсую программистские статьи. Но этой плюс поставить не смог — воздержался.

@kostik450 30 янв 2012 в 20:22

Я не обижаюсь, меня поражает уровень хабражителей, когда постишь 0-day комикс в ХабраЮмор получаешь гарантированно +50 в карму, а за техноманьячный пост про BOOL/BOOLEAN получаешь одни минуса. А хотелось бы наоборот.

Наверное, именно поэтому Хабраюмор убрали. Печаль.

@cypok 31 янв 2012 в 03:27

FYI: Я прочитал вашу статью и изначально поставил ей минус. Это было обоснованно тем, что вы использовали тип BOOLEAN, про который я впервые слышу в C++ (я не профи C++). И вывод «никогда не пользуйтесь BOOL, только BOOLEAN» удивил меня, так как я приверженец bool. Сейчас же я понимаю, что основной призыва не мешать BOOL и bool, но оценку уже не изменить, хотя статья действительно хорошая.

@EaS 31 янв 2012 в 04:13

Но ты же не в карму его поставил? А за статью. Автор говорит чуть-чуть о другом.

@cypok 31 янв 2012 в 04:29

Ну просто я спокойный человек, поставил за статью. Просто кто-то с аналогичными рассуждениями мог и в карму выстрелить.

@Andrey2008 31 янв 2012 в 05:17

Это да. Я уже забыл как свежие инвайты выглядят. Написать программистскую статью на 100, это ого-го…

НЛО прилетело и опубликовало эту надпись здесь

@Mithgol 31 янв 2012 в 05:01

Доброе утро, я и есть тот самый «некоторый», которого Вы имеете в виду: четыре последние захабренные блогозаписи во блоге о Mozilla Firefox (про работу с мобильною связью, про управление вибрацией, про переход на новую строку во всплывающих подсказках, про text-align-last) сочинил и опубликовал именно я.

С удивлением вижу, что, по-видимому, все мои статьи минусуют за то, что они посвящены использованию языков JavaScript да CSS в Firefox, а не Си++ в Visual Studio — и потому, стало быть, не технические да не программистские.

Вы уверены, что хотите жить в таком Хабрахабре, где все поступают так же, как Вы — минусуют статьи, далёкие от круга собственных интересов? Убеждён, что тогда Вашу статью одни читатели минусовали бы за то, что она не про iPhone, другие — за то, что она не про MD5 (да и вообще не про хэширование!…), третьи — за то, что она не про GPS (и даже не про ГЛОНАСС!…), четвёртые — за то, что она не помогает (совершенно, совершенно ничем не помогает, ну никакой пользы не приносит!…) в настройке беспроводных маршрутизаторов, пятые — за то, что она не про ВКонтакте (и даже ни слова в ней нет про LiveJournal или Twitter), а шестые — за то, что она не имеет никакого отношения не только к лечению компьютерных вирусов, но и к таможенным пошлинам на микропроцессоры.

Чтобы Вы почувствовали, как это будет, для начала позвольте поставить Вашей статье минус за то, что в ней, как ни старайся, не найдёшь ни строчки джаваскрипта или CSS. Веб-программистам эта статья совершенно бесполезна — ну и чего ей делать на заглавной странице Хабрахабра? Имею основания полагать, что и программисты на PHP, Python, Ruby и Erlang не найдут в ней ничего нового для себя. А тех лиц, которые сочиняют обзоры Убунты, наверняка не порадуют все вот эти чисто проприетарные виндоусовские заморочки — windows.h, WinDef.h — ну кого это может заинтересовать в мире открытых и свободных операционных систем?

И так далее.

Пишите во блоге о Си++ про свой Си++, а мне, уж пожалуйста, не мешайте писать во блоге Firefox про мой Firefox, не лезьте со своими минусами. Ведь на Хабрахабре не просто так создавались ≈280 различных блогов, посвящённые ≈280 совершенно различным направлениям и обстоятельствам айтишной жизни.

@kostik450 31 янв 2012 в 05:59

>Пишите во блоге о Си++ про свой Си++, а мне, уж пожалуйста, не мешайте писать во блоге Firefox

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

Но, появившись на главной, статья уже имеет достаточное количество плюсов и единичные минусы ей, по большому счету, никак не помешают.

@Mithgol 31 янв 2012 в 08:13

Ну да, а то я не знаю, как читают статьи не на главной, а в ленте, но всё же не подписываясь вручную на каждый тематический блог.

Сперва читатель Хабрахабра лезет в настройки ленты и жмякает там по первой галочке («Читать все»):

[скриншот]

Затем читатель с ужасом и отвращением видит, что бóльшая часть его ленты заполнена блогозаписями не про Си++. Какой кошмар! С этим надо что-то делать — например, заминусовать все их, насколько заряда хватит…

@kostik450 31 янв 2012 в 13:08

Как правило, галочку «Читать все» отмечает новичок, а у новичка заряда, чтобы минусовать карму нет, если его пригласили инвайтом. И нескоро появится. У меня это заняло 4 мес.

НЛО прилетело и опубликовало эту надпись здесь

@mark_ablov 30 янв 2012 в 16:28

Там еще и TRUE/FALSE вместо true/false смаку добавляют :)

@kostik450 30 янв 2012 в 18:23

Нет, ответ неверный. Убрал TRUE/FALSE для чистоты эксперимента.

НЛО прилетело и опубликовало эту надпись здесь

@Kirhgoff 30 янв 2012 в 16:41

А будет разоблачение черной магии? Пояснение, в чем же причина? Я вот так сразу не пойму, почему вначале выдает Equals. Правда на С++ не писал уже много-много лет.

@PavloG 30 янв 2012 в 16:52

sizeof(bool) != sizeof(BOOL) для данного случая
Строка:
(CallBack IsEqual = (CallBack)CompareInt;
кастит функцию возвращающую bool на функцию возвращающую int (BOOL)

Компилятор наверное ругнулся по этому поводу?

@kostik450 30 янв 2012 в 18:21

Нет, не ругнулся. Интересно, а PVS-Studio эту ситуацию как-то определяет? Вопрос знатокам.

@gribozavr 30 янв 2012 в 18:33

Такое определять легко, но смысла в этом мало, так как будет огромное количество false positives, так как C-style cast рассчитаны в том числе и на приведение несовместимых типов данных. Используйте нормальный static_cast в C++ и он вам будет давать ошибки компиляции когда вы это интуитивно ожидаете.

@Andrey2008 30 янв 2012 в 18:51

А что тут отлавливать? Явное приведение типа? Как тут уже заметили — ложных срабатываний будет 99.99% :-(. Собственно в реальном коде программиста должно остановить, что CallBack IsEqual = CompareInt; не будет компилироваться. А раз он гвоздиком прибил — значит так и надо.

@Andrey2008 30 янв 2012 в 19:03

Для педантов есть: V2005. C-style explicit type casting is utilized. Consider using: static_cast/const_cast/reinterpret_cast.

@EaS 30 янв 2012 в 16:52

А sizeof(bool) == sizeof(BOOL)? Там вообще нормальное приведение указателя на функцию?

@kostik450 30 янв 2012 в 18:26

Уже теплее.

@kekekeks 30 янв 2012 в 16:55

Это не чёрная магия, а зоопарк определений в виндовых включаемых файлах.

@kostik450 30 янв 2012 в 18:22

Это Майкрософт подложил свинью в виде своего проприетарного типа BOOL, который на самом деле int. Тянется, видимо, еще со времен Windows 2.0

@Andrey2008 30 янв 2012 в 18:54

Прям уж свинью. В нормальных книгах пишут, что BOOL это int. Да и просто программирую я в Windows сложно этого не заметить. Не вижу ничего плохого, что BOOL такой, какой он есть.

@gribozavr 30 янв 2012 в 18:56

Я не спорю, что нормальный программист должен это понимать, но согласитесь, иметь в одном языке bool, BOOL, BOOLEAN несовместимые друг с другом — плохая идея. Это как если бы были int, INT, INTEGER и все разной размерности.

@kostik450 30 янв 2012 в 19:50

Написал про разоблачение черной магии в UPD2 в самой статье.

@Andrey2008 30 янв 2012 в 16:56

1) Если в Си++ нужен логический тип данных, то следует использовать bool. Это стандартно, чётко, ясно, всем понятно.

2) В учебниках про Windows любят писать про тип BOOL в силу исторических причин. Многие функции из WinAPI возвращают или принимают тип BOOL. Который на самом деле int. Причины этого думаю понятны.

3) Я не понял причину вывода, что нужно использовать BOOLEAN.

@crea7or 30 янв 2012 в 17:08

А интересно, будет разница в коде и если да, то в скорости работы с BOOL и bool.

@ngreduce 30 янв 2012 в 17:13

нет, в конечном итоге принцип одинаковый. Просто процесс сравнения имеет тонкости.
Например проверять надо только на ложь.
А вообще это тянется со времен старого стандарта C

НЛО прилетело и опубликовало эту надпись здесь

@kostik450 30 янв 2012 в 18:29

1 и 2 пока не буду отвечать. А по пункту 3 — причина простая, с BOOLEAN все работает, а с BOOL нет. Поэтому и нужно использовать BOOLEAN.

@Andrey2008 30 янв 2012 в 18:59

С bool всё тоже будет работать. Так зачем лишние сущности? Вот что такое bool я знаю. А увидев BOOLEAN мне возможно придется идти смотреть его объявление.

@kostik450 30 янв 2012 в 19:54

Лишние сущности, действительно, ни к чему, но дело в том, что Windows API, видимо, рассчитан на чистый Си, а в Си нет типа bool, он появился только в C++. Так что во всем виноват не Майкрософт, а Страуструп (смайл).

@gribozavr 30 янв 2012 в 19:56

В современном Си (C99) есть bool. Но да, когда разрабатывали API NT, его не было.

@kostik450 30 янв 2012 в 20:03

Да, но Visual Studio 2010 дает ошибку на bool, если файл имеет расширение *.c (а не *.cpp)
Отсюда вывод, что C99 не поддерживается в Visual Studio 2010.

@Zigmar 30 янв 2012 в 19:06

И как всегда язык С++ путают с VisualC++ и подключенными виндовыми библиотеками… Я не раз сталкивался с людьми, которые искренне удивлялись, когда узнавали, что в языках С/С++ нету типов WORD и BYTE или функций вроде CreateFile.

@xanep 30 янв 2012 в 21:03

Нет языка Visual C++, это IDE. Все, что вы указали (WORD, BYTE, CreateFile) — это из Win API, никакого отношения к языку не имеет. А то, что люди забывают какие типы/ф-ии из языка, а какие из подключаемых библиотек — это распространенная проблема не только у программистов С++ под виндоуз.

@Zigmar 31 янв 2012 в 01:44

>Нет языка Visual C++, это IDE (...) это из Win API
Спасибо кэп, я как раз про тех людей, которые это не различают. А почему-то под другими платформами я не сталкивался что бы не различали, где язык, где библиотека а где IDE…

@Tishka17 31 янв 2012 в 02:41

Стандарт не читал. Мой g++ говорит:
ошибка: нет декларации «BOOLEAN» в этой области видимости
ошибка: нет декларации «BOOL» в этой области видимости

Так что юзаем bool и не выпендриваемся.

@EaS 31 янв 2012 в 04:11

По поводу UPD3, какие оптимизации использовались?

@kostik450 31 янв 2012 в 06:04

Оптимизации не использовались, но по ассемблерному коду видно, что Borland Builder при возврате false делает xor eax,eax и ошибки нет.

А на Visual Studio, повторюсь, делается mov al,0 и ошибка в том, что старшие биты eax не очищены.

@EaS 31 янв 2012 в 06:05

Но ведь он же может не сделать xor при -O2, например. И в этом случае еще сложнее было бы искать ошибку :)

@NickLion 31 янв 2012 в 05:23

А ошибка на самом деле в строке
CallBack IsEqual = (CallBack)CompareInt;
Привели к совершенно другому типу, ещё и удивляются, что не работает. Сигнатуру надо соблюдать. Если CallBack объявлен как BOOL (*)(int,int), то и функция должна иметь такой же прототип. Если нет — пишем обёртку и не надеемся на авось.

@kostik450 31 янв 2012 в 05:48

Немного истории. На самом деле — данный пример был взят из большого проекта для Windows, где вся команда пользовалась BOOL и не знала проблем. Но тут к проекту подключился один деятель, изначально он писал (да и сейчас пишет) на C#, а там, как известно, применяется только bool (маленькими буквами). Он-то и написал фунцию сравнения через возврат bool.

Мало того, функция 100% работает для чисел менее 0x100, потому что такие числа «не загрязняют» старшие биты регистра eax. Мало того, при сборке компилятор на это никак не ругнулся. Мало того, главный по коммитам (ведущий программист) видел, но пропустил этот код, потому что подумал, что BOOL это bool. Мало того, функция успела полгода пролежать в svn без изменений и все решили, что ошибки там быть не может. А когда я продемонстрировал ошибку, в проекте сразу сделали апперкейс всем bool/false/true, что на мой взгляд, сродни харакири, потому что проблема глубже, чем это кажется на первый взгляд.

А потом все удивляются, что фобос-грунты падают. Печаль.

@Andrey2008 31 янв 2012 в 06:07

Вообще-то, заменить bool на BOOL это тоже неверное решение. Как отметили, настоящая ошибка в том, что используется явное приведение типа. Это и есть причина ошибки, а не BOOL. Как это сделать? Можно приобрести PVS-Studio и просмотреть все явные касты в стиле Си.

А что у вас кстати с 64-битной вресией? Есть или планируете? А то вот где забавно с типами и явным приведением… ;)

@kostik450 31 янв 2012 в 09:45

64-битная версия готова! Как ни странно, версия для Windows пошла сразу же после перекомпиляции.

Если не считать небольших костылей в RegOpenKeyEx по работе с реестром:

#ifdef WIN64
    KEY_WOW64_32KEY
#else
    KEY_READ
#endif

Или несколько костылей в связи с изменением (улучшением) MFC:

#ifdef WIN64
    void CJoinDialog::OnTimer(UINT_PTR nIDEvent) 
#else
    void CJoinDialog::OnTimer(UINT nIDEvent) 
#endif

А вот с версией для x64 Linux пришлось изрядно повозиться, основная проблема была в том, что родной тип long там 64-х битовый. Поэтому все упоминания long в программе пришлось апперкейсить в LONG и далее превращать их принудительно в int:

#ifdef LINUX_x64
    typedef int LONG;
#else
    typedef long int LONG;
#endif

Совсем избавиться от long, превратив его везде в int нельзя, потому что нам нужна поддержка embedded процессоров, а они сплошь 16-ти битовые, то есть там sizeof(int)=2, что недостаточно, нам нужна точность 4 байта.

@Tujh 31 янв 2012 в 09:52

а про типв size_t и ptrdiff_t Вы, я так понимаю не слышали?

@kostik450 31 янв 2012 в 12:46

И причем здесь это? Нужен был тип, который гарантированно дает sizeof=4, для хранения там данных, передаваемых из девайса, не указателей и не индексов массивов. Неважно, знаковый он будет или беззнаковый.

На Java, кстати, там что 32 что 64 бита — int всегда один и тот же — знаковый 4 байта.
И long там всегда один и тот же, знаковый 8 байт. Что хорошо.

А на Си развели демократию, понимаешь.

@Tujh 31 янв 2012 в 13:01

sizeof( uint32_t ) == 4 всегда, что я делаю не так?

@Andrey2008 31 янв 2012 в 10:21

#ifdef WIN64

 void CJoinDialog::OnTimer(UINT_PTR nIDEvent) 

#else

 void CJoinDialog::OnTimer(UINT nIDEvent) 

#endif

Эээ… А зачем так? Почему не просто:
void CJoinDialog::OnTimer(UINT_PTR nIDEvent)

P.S. Я был бы поаккуратнее, говоря, что 64-битная пограмма пошла сразу после перекомпиляция :-). Вся подлянка, что часто только кажется, что работает. Приведу только один красивый пример: www.viva64.com/ru/b/0033/

@kostik450 31 янв 2012 в 12:06

Да кстати, да. Конечно, нужно UINT_PTR использовать.

@kostik450 31 янв 2012 в 09:21

>А потом все удивляются, что фобос-грунты падают. Печаль.

Я не удивлен, что в итоге выяснилось, что в падении Фобос-Грунта виноват программист

@Tujh 31 янв 2012 в 07:47

Жду от автора новых «откровений» про ошибки компиляции следующего выражения:
std::numeric_limits::max()
при подключенном <windows.h> и почему они лечатся макросом NOMINMAX

@kostik450 31 янв 2012 в 09:55

А откровения, чем отличается

#include <iostream>
#include <windows.h>
#include "stdafx.h"

случайно не интересны?

И почему там в одном месте кавычки, в другом треугольные скобки, да еще .h иногда отсутствует?
Кстати, это неплохой вопрос на собеседовании, уверен, что 90% на него не ответит — просто так принято.

Так и в нашем случае — писать BOOL это в среде Windows API общепринято, и ничего тут не поделать.

@Tujh 31 янв 2012 в 10:10

Вы явно не в теме. Кавычки тут не при чем.

Объясните следующий пример:

#include <limits>
#include <iostream>
#include <windows.h>


int main( int argc, char *argv[] )
{
    int _imax = std::numeric_limits< int >::max();
    std::cout << "int max = " << _imax << std::endl;

    return 0;
}

1>c:\project\source\tests\test_limith\main.cpp(9): warning C4003: not enough actual parameters for macro 'max'
1>c:\project\source\tests\test_limith\main.cpp(9): error C2589: '(': illegal token on right side of '::'
1>c:\project\source\tests\test_limith\main.cpp(9): error C2059: syntax error: '::'

И «писать BOOL это в среде Windows API общепринято» не факт… я не пишу.
Все, что выходит за рамки прямых вызовов WinAPI у меня на независимых типах uint8_t/sint16_t/size_t и т.п.

@kostik450 31 янв 2012 в 11:48

Ваш пример компилируется ошибкой, потому что в windows.h где-то есть #define max(a,b)
и поэтому препроцессор «портит» код. Лечится так:

#include <limits>
#include <iostream>
#include <windows.h>
#undef max

Ну или так, как Вы указали выше, через NOMINMAX, он тоже отключает #define max

@Tujh 31 янв 2012 в 13:00

#undef max

Я бы за это Вас по пальцам… указкой… деревянной… больно… до осознания!

1. Этот пример как раз из той же серии, что и Ваша статья — давно известно и разобрано по косточкам. К тому же специфично. BOOL и BOOLEAN равнонеправильны. В С++ правильно — bool, это встроенный тип.
LONG, UINT_PTR, BOOL — это не типы С++, это типы WinAPI и если их используете, то обязаны знать, что они из себя представляют. А значит «открытия» типа typedef int BOOL говорят как раз о незнании используемого инструмента и нежелании пользоваться поисковиками.

2. Кроме max() там еще и min() создается. Будете на каждый макрос undef делать?

3. Есть еще одно красивое решение, без макросов.

За снобизм извиняюсь, но порой без него не обойтись.

@kostik450 1 фев 2012 в 11:14

Самое грамотное решение такое — все, что связано с windows.h, все функции работы с WinAPI, нужно вынести в отдельный исходный файл своего проекта и написать к ним отдельный интерфейс. Потому что мешать в кучу старое и новое — неправильно. Так сказать, мухи отдельно, котлеты отдельно.

Я думаю, именно это Вы и имели в виду в пункте 3.

@Tujh 1 фев 2012 в 11:40

int _imax = (std::numeric_limits< int >::max)()

вот и все решение, не требуется ни макросов ни вынесения кода в отдельный интерфейс.

@kostik450 1 фев 2012 в 12:28

Да, красиво! Лишние скобочки еще никогда никому не вредили)))

НЛО прилетело и опубликовало эту надпись здесь

@kostik450 31 янв 2012 в 09:59

Вам сейчас подскажут, что CreateThread еще одно мегазло, нужно использовать _beginthread(ex), если этот поток потом использует CRT иначе тоже будет happy debugging.

@Andrey2008 31 янв 2012 в 10:23

Вы решили запустить PVS-Studio? :)

@kostik450 31 янв 2012 в 11:58

Я просто внимательно слежу за Вашими статьями и в одной из них было на эту тему.

Я потом специально посмотрел, а как у нас? Оказалось, у нас используется AfxBeginThread (которая из MFC), а она в итоге работает через _beginthreadex. Пронесло, подумал Штирлиц.

@Andrey2008 31 янв 2012 в 12:04

А сам PVS-Studio пробовали?

@kostik450 31 янв 2012 в 12:27

Пробовал достаточно давно, тогда ничего существенного найти не удалось.
Только memset(buf, sizeof(buf), 0);

@Andrey2008 31 янв 2012 в 12:39

На днях выйдет версия с новой моделью триала. Хороший повод вновь попробовать. Анализатор весьма активно развивается.

@Tujh 31 янв 2012 в 13:02

Что изменено в трале?

@Andrey2008 31 янв 2012 в 13:03

Про это будет статья.

@sand14 7 мар 2015 в 21:07

Недавно я тоже разместил статью про булевы типы (но в C#), поэтому, хотя тут обсуждение и давнее, хотелось быт поднять тему.

Вы провели хороший анализ, но я рекомендую придерживаться следующего:

1. Нативный булевский тип в C++ — это bool. Всегда используйте его с своих проектах.
Если пишите на чистом C, не поддерживающим bool, используйте в качество булева типа обычный int.
Считаю большой ошибкой использовать в своей вычислительной логике вместо стандартных типов языка типы, определенные как синонимы других типов в заголовочных файлах Windows SDK: BOOL, BOOLEAN, DWORD и т.д.
Если ваша программа может быть открыта как COM-объект, то стандартных типов данных в этом случае тоже хватит.

2. Что касается BOOL и BOOLEAN в WinAPI, то «правильный» тип — BOOL (C-Style: 32-битное целое, 0 — False, не-0 — True).
А тип BOOLEAN это Pascal-style, оставшийся в WinAPI в функциях, разработанных, когда в ранних версиях Windows API разрабатывался на паскале (1 байт, 0 — False, 1 — True).
Какой тип использовать в этом случае — определяется декларацией вызываемой функции WinAPI.
Если вы как-то в дальнейшей логике используете булевы значения, возвращенные API, то такие значение лучше сразу перевести в значения стандартного типа bool.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий