To bool or not to bool in C/C++ ?
-
An attempt to learn and make sense of evaluating results.
Making these assumptions, right or wrong
“bool” is not “standard” C/C++ type
when “condition” such as in “if(condition)” evaluates to true , it is binary zero
thus if(condition == 0) would make better sense
then if(condition)most “well written functions return x” , x being mostly zero when function is successful
when function fails – the return value is (generally) -1 or positive value identifying the error
then same as above - if(function (z) == 0) should prevail.Of course explicit evaluation of result to zero could prevent hard to locate bugs when these commonly used implicit evaluation conventions are not followed by author of the code..
Any other views / comments would be appreciated.
Vaclav_ wrote:
most "well written functions return x" , x being mostly zero when function is successful
Not necessarily; many functions return actual data rather than success/failure values. The decision on what to return depends on the requirements of the program. And as Carlo points out below, bool is a fundamental type in C++.
-
An attempt to learn and make sense of evaluating results.
Making these assumptions, right or wrong
“bool” is not “standard” C/C++ type
when “condition” such as in “if(condition)” evaluates to true , it is binary zero
thus if(condition == 0) would make better sense
then if(condition)most “well written functions return x” , x being mostly zero when function is successful
when function fails – the return value is (generally) -1 or positive value identifying the error
then same as above - if(function (z) == 0) should prevail.Of course explicit evaluation of result to zero could prevent hard to locate bugs when these commonly used implicit evaluation conventions are not followed by author of the code..
Any other views / comments would be appreciated.
Vaclav_ wrote:
"bool" is not "standard" C/C++ type
It is not clear what "standard" do you mean. According to wiki: Initial implementations of the language C (1972) provided no Boolean type... Standard C (since C99) provides a boolean type, called _Bool. By including the header stdbool.h, one can use the more intuitive name bool and the constants true and false. C++ has a separate Boolean data type bool So just check it out: [Boolean data type - Wikipedia](https://en.wikipedia.org/wiki/Boolean\_data\_type#C,\_C++,\_Objective-C,\_AWK)
-
An attempt to learn and make sense of evaluating results.
Making these assumptions, right or wrong
“bool” is not “standard” C/C++ type
when “condition” such as in “if(condition)” evaluates to true , it is binary zero
thus if(condition == 0) would make better sense
then if(condition)most “well written functions return x” , x being mostly zero when function is successful
when function fails – the return value is (generally) -1 or positive value identifying the error
then same as above - if(function (z) == 0) should prevail.Of course explicit evaluation of result to zero could prevent hard to locate bugs when these commonly used implicit evaluation conventions are not followed by author of the code..
Any other views / comments would be appreciated.
Quote:
"bool" is not "standard" C/C++ type
wrong
Quote:
when "condition" such as in "if(condition)" evaluates to true , it is binary zero
wrong
Quote:
thus if(condition == 0) would make better sense then if(condition)
wrong
Quote:
most "well written functions return x" , x being mostly zero when function is successful when function fails – the return value is (generally) -1 or positive value identifying the error then same as above - if(function (z) == 0) should prevail.
(Some) 'functions', yes, 'well written functions', no. To return an integer value of 0 as a sign of successfully finishing a function used to be the standard 30 years ago, because, most of the time, there was only one case of 'success' you were interested in, but potentially many cases os 'not success'. Since the type bool didn't exist back then, integers were used instead, and that opened the opportunity to use return values as error codes, where an error code of 0 was generally considered 'success'. Then, when the first attempts were made to introduce boolean types into the language (typically impementation-dependent), some people tried to adapt to this change by declaring the integer value of 1 as indicating success in functions that only ever returned 'success' or 'failure', rather than an error code. Unfortunately, that led to some confusion from the camp of programmers who liked the ability of returning various different error codes. This led to some unholy alliance of the different paradigms, where a value of 1, or, in fact, every positive value, was considered success, whereas negative values were considered error codes. These different methods of returning integer values with the dual meaning of 'success/'failure', as well as an error code has survived til today. But nowadays, the correct way to report an error is throwing an exception, not returning a value! This lets you use the return value in the original sense of a function: returning the result of the operation.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
-
An attempt to learn and make sense of evaluating results.
Making these assumptions, right or wrong
“bool” is not “standard” C/C++ type
when “condition” such as in “if(condition)” evaluates to true , it is binary zero
thus if(condition == 0) would make better sense
then if(condition)most “well written functions return x” , x being mostly zero when function is successful
when function fails – the return value is (generally) -1 or positive value identifying the error
then same as above - if(function (z) == 0) should prevail.Of course explicit evaluation of result to zero could prevent hard to locate bugs when these commonly used implicit evaluation conventions are not followed by author of the code..
Any other views / comments would be appreciated.
OK, essentially about using bool as a variable to evaluate only for two states C still has no standard ( AKA what used to be defined in " ANSI C standard " ) "type" bool Some coders just use #define - which is fine but hides the essential programming of checking something for these two values - sort of unnecessary crutch. C++ has "type" bool but evaluates to something called "true " or "false" which in reality is "something / application/ os " or whatever dependent and hides the binary value of these symbols. Hence no "standard" in sense of "ANSI C standard " again.
-
OK, essentially about using bool as a variable to evaluate only for two states C still has no standard ( AKA what used to be defined in " ANSI C standard " ) "type" bool Some coders just use #define - which is fine but hides the essential programming of checking something for these two values - sort of unnecessary crutch. C++ has "type" bool but evaluates to something called "true " or "false" which in reality is "something / application/ os " or whatever dependent and hides the binary value of these symbols. Hence no "standard" in sense of "ANSI C standard " again.
You are mixing C and C++, which only adds to your confusion. C++ and ANSI C are two distinct languages.
Vaclav_ wrote:
C++ has "type" bool but evaluates to something called "true " or "false" which in reality is "something / application/ os " or whatever dependent and hides the binary value ...
No. The
booltype in C++ is exactly that, a boolean type, and is part of the language, nothing to do with the operating system. A statement likebool someVariable = true;
while (somevariable)
{
// do stuff
}will continue until it encounters
someVariable = false;
But if you try
someVariable = 1;
the compiler may accept it byut you should not rely on it, as future compilers may well not accept it. And conversely if you try the first two in C the compiler will not know what you are talking about. Decide which language you want to use and stick to it, it will save you a lot of confusion.
-
OK, essentially about using bool as a variable to evaluate only for two states C still has no standard ( AKA what used to be defined in " ANSI C standard " ) "type" bool Some coders just use #define - which is fine but hides the essential programming of checking something for these two values - sort of unnecessary crutch. C++ has "type" bool but evaluates to something called "true " or "false" which in reality is "something / application/ os " or whatever dependent and hides the binary value of these symbols. Hence no "standard" in sense of "ANSI C standard " again.
Vaclav_ wrote:
C still has no standard ( AKA what used to be defined in " ANSI C standard " ) "type" bool
Wrong. As of C99 (1999! 30+ Years ago!), the standard defined _Bool, and include which includes the macros
#define bool _Bool
#define true 1
#define false 0In fact, in the comments to stdbool.h on my system I see
/*
* ISO C Standard: 7.16 Boolean type and values
*/Vaclav_ wrote:
C++ has "type" bool but evaluates to something called "true " or "false" which in reality is "something / application/ os " or whatever dependent and hides the binary value of these symbols. Hence no "standard" in sense of "ANSI C standard " again
Wrong again. The standard defines "true" and "false" as 0 and 1. Unless you use std::boolalpha, you normally get 0 or 1 when printing to an iostream (std::cout, etc). Technically I think that the implementation is free to use whatever values "behind the scenes" to implement a bool, but its representation is as if it had a value of 0 and 1. The same is true for
NULL. A given implementation may use any value it wishes to indicate a NULL pointer, but it has to act like a zero in certain contexts. I believe this was the case in the days when we had NEAR and FAR pointers. All the bits of a FAR NULL pointer might not be zero, as its segment selector might be set, but it would compare equal to zero, and equal to any other FAR NULL which had a different segment selector. -
Vaclav_ wrote:
C still has no standard ( AKA what used to be defined in " ANSI C standard " ) "type" bool
Wrong. As of C99 (1999! 30+ Years ago!), the standard defined _Bool, and include which includes the macros
#define bool _Bool
#define true 1
#define false 0In fact, in the comments to stdbool.h on my system I see
/*
* ISO C Standard: 7.16 Boolean type and values
*/Vaclav_ wrote:
C++ has "type" bool but evaluates to something called "true " or "false" which in reality is "something / application/ os " or whatever dependent and hides the binary value of these symbols. Hence no "standard" in sense of "ANSI C standard " again
Wrong again. The standard defines "true" and "false" as 0 and 1. Unless you use std::boolalpha, you normally get 0 or 1 when printing to an iostream (std::cout, etc). Technically I think that the implementation is free to use whatever values "behind the scenes" to implement a bool, but its representation is as if it had a value of 0 and 1. The same is true for
NULL. A given implementation may use any value it wishes to indicate a NULL pointer, but it has to act like a zero in certain contexts. I believe this was the case in the days when we had NEAR and FAR pointers. All the bits of a FAR NULL pointer might not be zero, as its segment selector might be set, but it would compare equal to zero, and equal to any other FAR NULL which had a different segment selector. -
Fortunately, at that time I was working on unix on Motorola 68000s. I never had to face the horrors of NEAR/FAR. But I heard about it. And praised all the gods that I didn't have to deal with it.
-
Vaclav_ wrote:
C still has no standard ( AKA what used to be defined in " ANSI C standard " ) "type" bool
Wrong. As of C99 (1999! 30+ Years ago!), the standard defined _Bool, and include which includes the macros
#define bool _Bool
#define true 1
#define false 0In fact, in the comments to stdbool.h on my system I see
/*
* ISO C Standard: 7.16 Boolean type and values
*/Vaclav_ wrote:
C++ has "type" bool but evaluates to something called "true " or "false" which in reality is "something / application/ os " or whatever dependent and hides the binary value of these symbols. Hence no "standard" in sense of "ANSI C standard " again
Wrong again. The standard defines "true" and "false" as 0 and 1. Unless you use std::boolalpha, you normally get 0 or 1 when printing to an iostream (std::cout, etc). Technically I think that the implementation is free to use whatever values "behind the scenes" to implement a bool, but its representation is as if it had a value of 0 and 1. The same is true for
NULL. A given implementation may use any value it wishes to indicate a NULL pointer, but it has to act like a zero in certain contexts. I believe this was the case in the days when we had NEAR and FAR pointers. All the bits of a FAR NULL pointer might not be zero, as its segment selector might be set, but it would compare equal to zero, and equal to any other FAR NULL which had a different segment selector. -
You are mixing C and C++, which only adds to your confusion. C++ and ANSI C are two distinct languages.
Vaclav_ wrote:
C++ has "type" bool but evaluates to something called "true " or "false" which in reality is "something / application/ os " or whatever dependent and hides the binary value ...
No. The
booltype in C++ is exactly that, a boolean type, and is part of the language, nothing to do with the operating system. A statement likebool someVariable = true;
while (somevariable)
{
// do stuff
}will continue until it encounters
someVariable = false;
But if you try
someVariable = 1;
the compiler may accept it byut you should not rely on it, as future compilers may well not accept it. And conversely if you try the first two in C the compiler will not know what you are talking about. Decide which language you want to use and stick to it, it will save you a lot of confusion.
-
Not to be an ass, but if we use #define true 1 how can it be technically called "standard (language ) type"? Then the language has something like #define int ... somewhere too? (just kidding )
\_Boolis the standard language type. When the standard was updated, it was realized that a lot of software had already created their own definitions of "bool" (either as a#define, or as atypedef). Therefore the standards committee chose \_Bool as least likely to collide with already written software (remember in C, identifiers starting with \_ are reserved for the implementation, i.e. not to be used in user programs). Thestdbool.hheader file was mandated so that new programs could have a "sensible" bool, true and false. It should be pointed out that all the standard says about \_Bool is that it be of unsigned integer type large enough to hold the values 0 and 1. In practice that means that a \_Bool is a synonym forunsigned char. However, if an implementation was to give \_Bool the equivalent ofunsigned long int, that is perfectly acceptable. In general, the standard says what a conforming implementation must do, and guarantees it must meet, but does not state how it must do so. For example the standard sayssizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long)
You can see this for yourself where in 32 bit land usually,
sizeof(int) = 4
sizeof(long) = 4
sizeof(long long) = 8but in 64 bit land
sizeof(int) = 4
sizeof(long) = 8
sizeof(long long) = 8In 16 bit land, it was often
sizeof(short) == sizeof(int) == 2. This difference in sizes has caught many developers off guard when moving from 32 bit to 64 compilers, where assumptions about the size of various basic types were hard-wired into the program. Indeed, the linux kernel and associated libs are still dealing with this in terms of time_t moving from a 32 bit value to 64. For example, the range of a 64 bit time_t is approximately +/- 2.9E11 years. That means converting a large value of time_t to astruct tmcurrently has problems sincestruct tmdefines tm_year as an int, which jas a range of approx. +/- 2.1E9, which is smaller by a factor of ~100. That's probably not an issue I will ever need to deal with, but I would not be surprised if something, somewhere is making assumptions about convertingtime_ttostruct tmthat's going to produce unexpected results based on "max value" of a time_t. -
Vaclav_ wrote:
"bool" is not "standard" C/C++ type
It is not clear what "standard" do you mean. According to wiki: Initial implementations of the language C (1972) provided no Boolean type... Standard C (since C99) provides a boolean type, called _Bool. By including the header stdbool.h, one can use the more intuitive name bool and the constants true and false. C++ has a separate Boolean data type bool So just check it out: [Boolean data type - Wikipedia](https://en.wikipedia.org/wiki/Boolean\_data\_type#C,\_C++,\_Objective-C,\_AWK)
By "standard" I was referring to your definition of "1972 C language" which did not have "type" of bool. As a side question then where did the "true = 1 " and "false = 0 " convention came from ? It seems that it is just the opposite true = 0 and false = 1 which is commonly in use , without actually referencing "true" or "false". I have never seen if(condition == true) , but if(condition) often assumes condition == 0 as true. Of course "it depends on who coded the software" is obvious catch all.
-
By "standard" I was referring to your definition of "1972 C language" which did not have "type" of bool. As a side question then where did the "true = 1 " and "false = 0 " convention came from ? It seems that it is just the opposite true = 0 and false = 1 which is commonly in use , without actually referencing "true" or "false". I have never seen if(condition == true) , but if(condition) often assumes condition == 0 as true. Of course "it depends on who coded the software" is obvious catch all.
Vaclav_ wrote:
By "standard" I was referring to your definition of "1972 C language" which did not have "type" of bool.
My Goodness!!!!! No wonder you are confused. NOBODY uses C72 except in DIRE circumstances. The only time I've used C72 in the last 30 years is to bootstrap into gcc. C72 didn't have
void. or function prototypes. In K&R C you defined functions as:func(x, y)
int x;
double y;
{
/* function body */
/* implicitly returns int, which is
* value of last statement if no
* explicit return
*/
}The ISO standard for C didn't appear until 1989, and that's been superseded by C99 and C11. You should at least be using C89. Preferably C11. Get with the current century, man!
-
An attempt to learn and make sense of evaluating results.
Making these assumptions, right or wrong
“bool” is not “standard” C/C++ type
when “condition” such as in “if(condition)” evaluates to true , it is binary zero
thus if(condition == 0) would make better sense
then if(condition)most “well written functions return x” , x being mostly zero when function is successful
when function fails – the return value is (generally) -1 or positive value identifying the error
then same as above - if(function (z) == 0) should prevail.Of course explicit evaluation of result to zero could prevent hard to locate bugs when these commonly used implicit evaluation conventions are not followed by author of the code..
Any other views / comments would be appreciated.
As many have stated true = 1, false = 0 you had it wrong. However reason for post is to advise you to read what has been stated from the standards group <stdbool.h>[Link to standard]
Quote:
FUTURE DIRECTIONS The ability to undefine and redefine the macros bool, true, and false is an obsolescent feature and may be withdrawn in a future version.
So code using it's own definitions of true or false may drop dead in future versions of C standards and can not be compiled on compilers using the new standards ... you have been warned.
In vino veritas
-
Richard, why are you getting into your typical " blame the poster " mode? I am not confused, just asked / posted a question and do not appreciate such comments. "get off my lawn..."
-
As many have stated true = 1, false = 0 you had it wrong. However reason for post is to advise you to read what has been stated from the standards group <stdbool.h>[Link to standard]
Quote:
FUTURE DIRECTIONS The ability to undefine and redefine the macros bool, true, and false is an obsolescent feature and may be withdrawn in a future version.
So code using it's own definitions of true or false may drop dead in future versions of C standards and can not be compiled on compilers using the new standards ... you have been warned.
In vino veritas
-
Since coders - both C and C++ -cannot AGREE which way is up, I'll continue to evaluate MOST BINARY conditions explicitly to its binary values. Problem solved. Now let's solve Mac or Windows next. Have s well day,ya'l.
-
Not only does he not realize that statement is incorrect what he plans to do is also going to give bugs. He is going to test for the value of true by "== 1" :-) There is another subtlety that on compares with C/C++ any other value than 0 is true. Windows and Linux both use that extensively especially on API call returns They know a function hands back a register for a bool (not a bit) so they actively exploit it Even consider normal things you see like
void* P = malloc(100);
if (p)
{
// use p as it's valid
}You can't write the true case simply ... the reality is the actual test is p != 0. The moment you get MACROS you actually have no idea what the expansions are and he will end up doing things like testing "p == 1" above ... which would be an amusing bug. It's actually amusing how many problems you can create in some crazy attempt to fix a non existent problem based on total misunderstanding :-)
In vino veritas
-
Not only does he not realize that statement is incorrect what he plans to do is also going to give bugs. He is going to test for the value of true by "== 1" :-) There is another subtlety that on compares with C/C++ any other value than 0 is true. Windows and Linux both use that extensively especially on API call returns They know a function hands back a register for a bool (not a bit) so they actively exploit it Even consider normal things you see like
void* P = malloc(100);
if (p)
{
// use p as it's valid
}You can't write the true case simply ... the reality is the actual test is p != 0. The moment you get MACROS you actually have no idea what the expansions are and he will end up doing things like testing "p == 1" above ... which would be an amusing bug. It's actually amusing how many problems you can create in some crazy attempt to fix a non existent problem based on total misunderstanding :-)
In vino veritas