To bool or not to bool in C/C++ ?
-
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
-
... with only one exception: if someone agrees with him! :^)