Товарищи

В файле windef.h есть такая строчка

#define int BOOL

Вопрос:
Зачем вообще нужен этот тип и чем он лучше bool.

Здравствуйте, globus000, Вы писали:

G>Товарищи

G>В файле windef.h есть такая строчка

G>#define int BOOL
Он используется как для C, так и для C++.

G>Вопрос:
G>Зачем вообще нужен этот тип и чем он лучше bool.
IMHO::
Он не лучше, а хуже. Хуже хотя бы тем, что он в 4 раза больше bool.
Это одна из попыток промоделировать работу булевского типа данных, коего нет в C.
А как пишет Саттер, булевский тип средствами C создать нельзя, значит, если надо просто булевский тип, то используй bool.
Но если ты взаимодействуешь с API, где используется BOOL, то используй BOOL.

Здравствуйте, globus000, Вы писали:

G>Товарищи

G>В файле windef.h есть такая строчка

G>#define int BOOL

G>Вопрос:
G>Зачем вообще нужен этот тип и чем он лучше bool.


Проблема классического типа bool состоит в том, что он позволяет опреровать лишь с двумерными флагами, в силу ограниченности диапазона допустимых значений этого типа двумя значениями — true и false.

Тип BOOL — является преопределением типа int и несет такую же смысловую нагрузку что и bool. Он позволяет сохранить все возможности классических флагов, но добавляет новую возможность — многомерность флага.

Здравствуйте, globus000, Вы писали:

G>#define int BOOL

G>Вопрос:
G>Зачем вообще нужен этот тип и чем он лучше bool.

Нужен чтобы обозначить, что некая функция Windows API принимает булевский параметр или возвращает булево значение.
Лучше bool он тем, что доступен в Си, а также был доступен в Си++ тогда, когда в последнем типа bool не было.
Он был введен в седую старину проектировщиками Windows API.

Здравствуйте, Slick, Вы писали:

S>Здравствуйте, globus000, Вы писали:

G>>Товарищи

G>>В файле windef.h есть такая строчка

G>>#define int BOOL

G>>Вопрос:
G>>Зачем вообще нужен этот тип и чем он лучше bool.


S>Проблема классического типа bool состоит в том, что он позволяет опреровать лишь с двумерными флагами, в силу ограниченности диапазона допустимых значений этого типа двумя значениями — true и false.

S>Тип BOOL — является преопределением типа int и несет такую же смысловую нагрузку что и bool. Он позволяет сохранить все возможности классических флагов, но добавляет новую возможность — многомерность флага.

Работа с двумерными флагами — конечно дело хорошее но мне не понятно почему этот тип назван BOOL.
Если я не ошибаюсь, в булевой алгебре может быть только 2 значения — истина/ложь. А тут у наспоявляется тип, претендующий на то чтобы быть булевым, но принимающий совсем иные значения.
То есть если я читаю код и вижу что метод возвращает BOOL логитчно предположить что значения будут TRUE/FALSE а не 1243 или 15. Не кажется ли вам, многоуважаемые, что это нескольок сбивает с толку и вводит неоднозначность.
(Если бы он назывался скажем FLAG было бы яснее)

G>>Вопрос:
G>>Зачем вообще нужен этот тип и чем он лучше bool.
S>IMHO::
S>Он не лучше, а хуже. Хуже хотя бы тем, что он в 4 раза больше bool.

Ну, это ты погорячилcя — размер bool-а зависит от реализации. О размере була можно лишь утверждать следующее:

1 <= sizeof(bool) <= sizeof(long)

Здравствуйте, Slick

S>Тип BOOL — является преопределением типа int и несет такую же смысловую нагрузку что и bool. Он позволяет сохранить все возможности классических флагов, но добавляет новую возможность — многомерность флага.
IMHO Многомерный bool — извращение , он нарушает саму природу этого типа данных. BOOL , не являющийся true и false одновременно — все равно, что слегка беременная.

Здравствуйте, Другой Аноним, Вы писали:

ДА>Здравствуйте, globus000, Вы писали:

G>>#define int BOOL

G>>Вопрос:
G>>Зачем вообще нужен этот тип и чем он лучше bool.

ДА>Нужен чтобы обозначить, что некая функция Windows API принимает булевский параметр или возвращает булево значение.
ДА>Лучше bool он тем, что доступен в Си, а также был доступен в Си++ тогда, когда в последнем типа bool не было.
ДА>Он был введен в седую старину проектировщиками Windows API.

То есть объяснение такое
"В С++ нет типа bool а нам нужно что-то для обозначения логических операций
Поэтому вводим BOOL"
Но почему int.
Почему не ограничить двумя значениями true/false.

Здравствуйте, Анатолий Широков

АШ>Ну, это ты погорячилcя — размер bool-а зависит от реализации. О размере була можно лишь утверждать следующее:

Sorry.
Согласен с критиокй.


Но все равно, IMHO если можно обойтись средствами языка, надо ими обходится — код будет более переносимым. Так что, если есть возможность, я бы предпочел bool.

Здравствуйте, skyline, Вы писали:

S>IMHO Многомерный bool — извращение , он нарушает саму природу этого типа данных. BOOL , не являющийся true и false одновременно — все равно, что слегка беременная.

Тем не менее и объект типа bool может быть не равным ни true, ни false.

Здравствуйте, globus000, Вы писали:

G>Здравствуйте, Slick, Вы писали:

S>>Здравствуйте, globus000, Вы писали:

G>>>Товарищи

G>>>В файле windef.h есть такая строчка

G>>>#define int BOOL

G>>>Вопрос:
G>>>Зачем вообще нужен этот тип и чем он лучше bool.


S>>Проблема классического типа bool состоит в том, что он позволяет опреровать лишь с двумерными флагами, в силу ограниченности диапазона допустимых значений этого типа двумя значениями — true и false.

S>>Тип BOOL — является преопределением типа int и несет такую же смысловую нагрузку что и bool. Он позволяет сохранить все возможности классических флагов, но добавляет новую возможность — многомерность флага.

G>Работа с двумерными флагами — конечно дело хорошее но мне не понятно почему этот тип назван BOOL.
G>Если я не ошибаюсь, в булевой алгебре может быть только 2 значения — истина/ложь. А тут у наспоявляется тип, претендующий на то чтобы быть булевым, но принимающий совсем иные значения.
G>То есть если я читаю код и вижу что метод возвращает BOOL логитчно предположить что значения будут TRUE/FALSE а не 1243 или 15. Не кажется ли вам, многоуважаемые, что это нескольок сбивает с толку и вводит неоднозначность.
G>(Если бы он назывался скажем FLAG было бы яснее)

Пардон — читать "Работа с многомерными флагами...."

Здравствуйте, Другой Аноним

ДА>Тем не менее и объект типа bool может быть не равным ни true, ни false.
Приведи пример.
А вообще, если так, то станет очень грусно.

Здравствуйте, skyline, Вы писали:

S>Здравствуйте, Slick

S>>Тип BOOL — является преопределением типа int и несет такую же смысловую нагрузку что и bool. Он позволяет сохранить все возможности классических флагов, но добавляет новую возможность — многомерность флага.
S>IMHO Многомерный bool — извращение , он нарушает саму природу этого типа данных. BOOL , не являющийся true и false одновременно — все равно, что слегка беременная.

Не было в C bool-а поэтому считали, что (i != 0) == TRUE, (i == 0) == FALSE. А все пошло от того, что оперировать байтами (словами, двойными словами) на порядок быстрее, чем оперировать битами.

Здравствуйте, Другой Аноним, Вы писали:

ДА>Здравствуйте, skyline, Вы писали:

S>>IMHO Многомерный bool — извращение , он нарушает саму природу этого типа данных. BOOL , не являющийся true и false одновременно — все равно, что слегка беременная.

ДА>Тем не менее и объект типа bool может быть не равным ни true, ни false.

Конечно не может
Он или положительно определен или отрицательно.
если мы напишем
int main(int argc, char* argv[])
{
bool is_empty;

if(is_empty)
{
cout<<"empty"<<endl;;
}esle{
cout<<"not empty"<<endl;
}

return 0;
}

то будет выдано обязательно одно из этих сообщений.
А это значит что он всегда определен.

Здравствуйте, globus000, Вы писали:

G>То есть объяснение такое
G>"В Си нет типа bool а нам нужно что-то для обозначения логических операций
G>Поэтому вводим BOOL"
G>Но почему int.
G>Почему не ограничить двумя значениями true/false.

Ну, наверное просто решили упростить, следуя уже имевшейся практике возврата int из функций в интерфейсах на Си.

Здравствуйте, skyline, Вы писали:

ДА>>Тем не менее и объект типа bool может быть не равным ни true, ни false.

S>Приведи пример.
S>А вообще, если так, то станет очень грусно.

См. сноску 42 к 3.9.1(6) в стандарте языка.

Здравствуйте, globus000, Вы писали:

ДА>>Тем не менее и объект типа bool может быть не равным ни true, ни false.

G>Конечно не может

Предлагаю ознакомится со стандартом:

3.9.1/6
...
примечение 42:
Using a bool value in ways described by this International Standard as ‘‘undefined,’’ 
such as by examining the value of an uninitialized automatic variable, 
might cause it to behave as if is neither true nor false.

А результат работы приведенного кода не что иное, как один из вариантов "undefined behavior"

Здравствуйте, Bell, Вы писали:

B>Здравствуйте, globus000, Вы писали:

ДА>>>Тем не менее и объект типа bool может быть не равным ни true, ни false.

G>>Конечно не может

B>Предлагаю ознакомится со стандартом:

B>

B>3.9.1/6
B>...
B>примечение 42:
B>Using a bool value in ways described by this International Standard as ‘‘undefined,’’ 
B>such as by examining the value of an uninitialized automatic variable, 
B>might cause it to behave as if is neither true nor false.
B>

B>

B>А результат работы приведенного кода не что иное, как один из вариантов "undefined behavior"

Согласен

Здравствуйте, globus000, Вы писали:

G>Но почему int.
G>Почему не ограничить двумя значениями true/false.

Потому что это int — это машинное слово. (Не в смысле WORD, а в смысле размер регистра).

Допустим, мы выяснили, что для (true,false) достаточно 1 байта (char).
Теперь мы имеем секс:
— при передаче in-параметра в функцию: нужно расширить char до размера слова стека (а это — все тот же int)
— при возврате — обрезать регистр возврата до char (в старших байтах — может быть мусор!)

Ладно, это на платформе x86 делается достаточно просто: используем регистр AL-AX-EAX-(что там на 64битных процах).
Но все равно: зачем заниматься дополнительными действиями?

Как правило, тип BOOL используется только в вызовах функций, а не в структурах, поэтому давиться жабой за каждый байт нет смысла.
Кстати говоря, в структурах вообще не стоит использовать платформенно-зависимые типы (int таковым является) — от этого страдает переносимость.

Еще один момент состоит в следующем:
bool == { 0, 1 } по определению.
BOOL == { 0, что-угодно-но-не-ноль }.
Этим можно пользоваться. Например, возвращать целое число, которое равно 0 тогда и только тогда, когда возвращать нужно ложь.

BOOL not_empty_string(const char* s)
{
  return s[0];
}

BOOL not_empty_file(HFILE hFile)
{
  return FileSize(hFile);
}

Конечно, это хак, но тем не менее.

В любом случае, документация MSDN гарантирует, что некая BOOL Fooo(...) возвращает ненулевое значение как истинное.
Трактовать его результат как 1 нельзя.

Здравствуйте, Другой Аноним, Вы писали:

ДА>был доступен в Си++ тогда, когда в последнем типа bool не было.

То есть в C++ изначально не было bool?

Здравствуйте, Jenyay, Вы писали:

J>То есть в C++ изначально не было bool?

Ну да, он же родом из детства. В смысле из Си. bool добавили уже в середине 90-х.

Здравствуйте, Кодт, Вы писали:

К>Здравствуйте, globus000, Вы писали:

G>>Но почему int.
G>>Почему не ограничить двумя значениями true/false.

К>Потому что это int — это машинное слово. (Не в смысле WORD, а в смысле размер регистра).

К>Допустим, мы выяснили, что для (true,false) достаточно 1 байта (char).
К>Теперь мы имеем секс:
К>- при передаче in-параметра в функцию: нужно расширить char до размера слова стека (а это — все тот же int)
К>- при возврате — обрезать регистр возврата до char (в старших байтах — может быть мусор!)

К>Ладно, это на платформе x86 делается достаточно просто: используем регистр AL-AX-EAX-(что там на 64битных процах).
К>Но все равно: зачем заниматься дополнительными действиями?

Ну это я и так знаю, спасибо )))

К>Как правило, тип BOOL используется только в вызовах функций, а не в структурах, поэтому давиться жабой за каждый байт нет смысла.
К>Кстати говоря, в структурах вообще не стоит использовать платформенно-зависимые типы (int таковым является) — от этого страдает переносимость.

К>Еще один момент состоит в следующем:
К>bool == { 0, 1 } по определению.
К>BOOL == { 0, что-угодно-но-не-ноль }.
К>Этим можно пользоваться. Например, возвращать целое число, которое равно 0 тогда и только тогда, когда возвращать нужно ложь.
К>

К>BOOL not_empty_string(const char* s)
К>{
К>  return s[0];
К>}

К>BOOL not_empty_file(HFILE hFile)
К>{
К>  return FileSize(hFile);
К>}
К>

К>Конечно, это хак, но тем не менее.

К>В любом случае, документация MSDN гарантирует, что некая BOOL Fooo(...) возвращает ненулевое значение как истинное.
К>Трактовать его результат как 1 нельзя.

А на этом моменте давайте чуток подробнее. Я понимаю, что мы можем опсредством этого тип вернуть код завершения операции, отличный от 1/0. Но мне лично этот тип не нравится по следующим причинам.
Он вночсит разнобой при чтении кода так как я могу в одном месте видеть сравнения переменной типа BOOL с FALSE/TRUE а в другом с константами типа 15, 123 и тп. Посему не было введено ограничение на тип BOOL такое же как и на bool
BOOL = { 0 , 1} — два инта, никаких автоприведений к машинному слову, все зашибись.
Да и логически очень паршиво воспринимается булевая переменная, которая может принимать значения отличные от ИСТИНА/ЛОЖЬ.
просто как мне кажется объявление BOOL равносильно тому, что я напишу

#define double INT

Выглядит немного дико.

Здравствуйте, skyline, Вы писали:

S>Здравствуйте, Анатолий Широков

АШ>>Ну, это ты погорячилcя — размер bool-а зависит от реализации. О размере була можно лишь утверждать следующее:

S>Sorry.
S>Согласен с критиокй.


S>Но все равно, IMHO если можно обойтись средствами языка, надо ими обходится — код будет более переносимым. Так что, если есть возможность, я бы предпочел bool.

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

Здравствуйте, globus000, Вы писали:

G>Я понимаю, что мы можем опсредством этого тип вернуть код завершения операции, отличный от 1/0. Но мне лично этот тип не нравится по следующим причинам.
G>Он вночсит разнобой при чтении кода так как я могу в одном месте видеть сравнения переменной типа BOOL с FALSE/TRUE а в другом с константами типа 15, 123 и тп. Посему не было введено ограничение на тип BOOL такое же как и на bool
G>BOOL = { 0 , 1} — два инта, никаких автоприведений к машинному слову, все зашибись.
G>Да и логически очень паршиво воспринимается булевая переменная, которая может принимать значения отличные от ИСТИНА/ЛОЖЬ.
G>просто как мне кажется объявление BOOL равносильно тому, что я напишу

G>#define double INT

G>Выглядит немного дико.

Я вот использую следующее правило что бы не было всяких глюков в проге:
Никогда не писать так

BOOL b = ......
if(b == TRUE) ........

А пишу так

BOOL b = ......
if(b != FALSE) ........

Просто один раз я вылавливал баг на такой строчке оч долго.

ЗЫ: К томуже TRUE != VARIANT_TRUE , вот это уже меня совсем добило.

Здравствуйте, Denwer

D>ЗЫ: К томуже TRUE != VARIANT_TRUE , вот это уже меня совсем добило.
Меня тоже это бесит

G>>Он вночсит разнобой при чтении кода так как я могу в одном месте видеть сравнения переменной типа BOOL с FALSE/TRUE а в другом с константами типа 15, 123 и тп. Посему не было введено ограничение на тип BOOL такое же как и на bool
G>>BOOL = { 0 , 1} — два инта, никаких автоприведений к машинному слову, все зашибись.
G>>Да и логически очень паршиво воспринимается булевая переменная, которая может принимать значения отличные от ИСТИНА/ЛОЖЬ.

G>>Выглядит немного дико.

Иногда в программе бывает полезно, чтобы логическая переменная принимала не только значения ИСТИНА/ЛОЖЬ, но и некое третье значение. Конечно, догматики и Почитатели Стандарта не согласятся со мной, но программисты, которые пишут программы наверняка сталкивались с этим. Да и житейская логика говорит, что кроме ДА и НЕТ встречается еще НЕ_ЗНАЮ.
D>Я вот использую следующее правило что бы не было всяких глюков в проге:
D>Никогда не писать так
D>

D>BOOL b = ......
D>if(b == TRUE) ........
D>

D>А пишу так
D>

D>BOOL b = ......
D>if(b != FALSE) ........
D>

Еще лучще писать

if(b) ........
if(!b) ........

особенно если логической переменной дать подходящее имя (оно должно быть прилагательным)

Здравствуйте, skyline, Вы писали:

D>>ЗЫ: К томуже TRUE != VARIANT_TRUE , вот это уже меня совсем добило.
S>Меня тоже это бесит

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

D>>>ЗЫ: К томуже TRUE != VARIANT_TRUE , вот это уже меня совсем добило.
S>>Меня тоже это бесит

ДА>Всех больше это наверное бесит парней из Microsoft, которые вынуждены регулярно пользоваться и тем, и тем.

если писать if(b) то все будет работать независимо от типа b

Здравствуйте, SWW, Вы писали:

SWW>если писать if(b) то все будет работать независимо от типа b

Особенно учитывая S_FALSE == 1.

SWW>>если писать if(b) то все будет работать независимо от типа b

А>Особенно учитывая S_FALSE == 1.

S_FALSE — это HRESULT, он проверяется известными макросами и приплетать его сюда IMHO не совсем корректно

Здравствуйте, SWW, Вы писали:

А>>Особенно учитывая S_FALSE == 1.

SWW>S_FALSE — это HRESULT, он проверяется известными макросами и приплетать его сюда IMHO не совсем корректно

Какими именно?

А>>>Особенно учитывая S_FALSE == 1.

SWW>>S_FALSE — это HRESULT, он проверяется известными макросами и приплетать его сюда IMHO не совсем корректно

А>Какими именно?

FAILED и SUCCEDED разве недостаточно известны чтобы выделять это слово?

Здравствуйте, SWW, Вы писали:

SWW>>>S_FALSE — это HRESULT, он проверяется известными макросами и приплетать его сюда IMHO не совсем корректно

А>>Какими именно?

SWW>FAILED и SUCCEDED разве недостаточно известны чтобы выделять это слово?

Как сии макросы помогут различить S_OK и S_FALSE?

Здравствуйте, SWW, Вы писали:

А>>>Особенно учитывая S_FALSE == 1.

SWW>>S_FALSE — это HRESULT, он проверяется известными макросами и приплетать его сюда IMHO не совсем корректно

А>Какими именно?

SWW>FAILED и SUCCEDED разве недостаточно известны чтобы выделять это слово?

Расскажи мне, как ты с помощью этих макросов будешь S_OK от S_FALSE отличать?

Ed.ward

Здравствуйте, SWW, Вы писали:

SWW>>>S_FALSE — это HRESULT, он проверяется известными макросами и приплетать его сюда IMHO не совсем корректно

А>>Какими именно?

SWW>FAILED и SUCCEDED разве недостаточно известны чтобы выделять это слово?

S_OK, S_FALSE — оба SUCCEEDED

Здравствуйте, Другой Аноним, Вы писали:

ДА>>> Тем не менее и объект типа bool может быть не равным ни true, ни false.
S>> ...
ДА> См. сноску 42 к 3.9.1(6) в стандарте языка.

Ровно в той же мере это относится к любым типам. В частности, например, использование значения
неинициализированной переменной типа int может привести к тому, что последовательное сравнение
этого "значения" со всеми значениями диапазона INT_MIN .. INT_MAX вернет false во всех случаях.
Undefined есть undefined. Короче говоря, в "нормальном" случае bool не может быть ничем, кроме
true или false, так же, как значение типа int должно равняться одному из значений в диапазоне
INT_MIN .. INT_MAX.

Здравствуйте, globus000, Вы писали:

G>Товарищи

G>В файле windef.h есть такая строчка

G>#define int BOOL

G>Вопрос:
G>Зачем вообще нужен этот тип и чем он лучше bool.
Отвечаю именно на первый вопрос, так как опять развели флейм!
BOOL — это просто #define int BOOL. Можно посмотреть в каком-то include-windows файле — поищи сам.
BOOL был введен разработчиками Windows достаточно давно, когда bool еще на свете не было. При работе с функциями Windows API предпочтительно, во избежание всяческих эффектов, использовать BOOL. Если программишь на С++, не влезая в API, то надо использовать родной для С++ bool. Смешивать — лучше не надо, от греха ...

G>Вопрос:
G>Зачем вообще нужен этот тип и чем он лучше bool.

тип BOOL в Windows это на самом деле 32-битное целое
широко используется при взаимодействии с другими языками программирования
и библиотеками , в которых нет bool (C, VB, COM)

Здравствуйте, Awaken, Вы писали:

G>Вопрос:
G>Зачем вообще нужен этот тип и чем он лучше bool.

A>тип BOOL в Windows это на самом деле 32-битное целое
A>широко используется при взаимодействии с другими языками программирования
A>и библиотеками , в которых нет bool (C, VB, COM)

VB и COM лучше убери из этого списка, потому как там используется VARIANT_BOOL

Ed.ward

Здравствуйте, Ed.ward, Вы писали:

A>>тип BOOL в Windows это на самом деле 32-битное целое
A>>широко используется при взаимодействии с другими языками программирования
A>>и библиотеками , в которых нет bool (C, VB, COM)

EW>VB и COM лучше убери из этого списка, потому как там используется VARIANT_BOOL

COM еще может использовать S_OK == 0 | S_FALSE == 1

Здравствуйте, SWW

Но это не булевский тип данных. Булевский тип данных — "это лампочка, которая либо горит, либо не горит"

На самом деле нужно взглянуть на это дело более широко.

Windows API — интерфейс, посредством которого приложения получают доступ к системным функциям среды. Интерфейс этот "бинарный", то есть, он определяется на уровне таких "низменных" материй, как порядок передачи параметров через стек, размер этих параметров, используемый способ выравнивания структур и т. п.

Язык Си, который "от рождения" являлся довольно низкоуровневым, хорошо справляется с определением таких интерфейсов. Для этого достаточно определить ряд соглашений, связанных с платформой (ну, например, наличие поддержки способа вызова __pascal или наличие двухбайтного целочисленного типа).

Однако он является не единственным потенциальным языком написания приложений.

Например, мы могли бы писать прикладное ПО на Паскале, Модуле, Бейсике, Аде или Фортране. Могли бы изобрести собственный язык программирования.

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

Естественно определить некий набор примитивных типов, соответствующих нуждам, основываясь на специфике платформы. Например, для Win16 мы имели INT, UINT, LONG, ULONG, WORD, DWORD, BYTE и т. п. Типы языка Си (int, long и т. п.) изначально в программном интерфейсе Windows не использовались вовсе.

Для описания специального предназначения определенных данных нужен тип BOOL. Он также должен быть примитивным типом. То есть невозможно определить его как-то более подробно, чем некий аппаратный тип; на роль такого аппаратного типа лучше всех подходит INT по причинам, которые здесь уже приводились.