|
|
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
Well... Fundamental types - cppreference.com[^], Boolean type support library - cppreference.com[^].
Quote: 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.
In C++, if a function returns a bool then using
if ( function(x) ) is the only meaningful way I see.
On the other hand, if the function returns an integer data type, then
if (function(x) == expected_int_result) is the most sensible approach.
|
|
|
|
|
Hello,
perhaps there's a confusion with older versions of C language where bool was not a standard type.
But in all cases :
"when "condition" such as in "if(condition)" evaluates to true, it is binary zero" is false !
cppreference.com[^] : If the source type is bool, the value false is converted to zero and the value true is converted to the value one of the destination type (note that if the destination type is int, this is an integer promotion, not an integer conversion).
|
|
|
|
|
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++.
|
|
|
|
|
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
|
|
|
|
|
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;
{
}
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!
|
|
|
|
|
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)
|
|
|
|
|
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 bool type in C++ is exactly that, a boolean type, and is part of the language, nothing to do with the operating system. A statement like
bool someVariable = true;
while (somevariable)
{
}
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.
|
|
|
|
|
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..."
|
|
|
|
|
Who is blaming? I merely mentioned out that you are confusing things by mixing two different languages. But as usual you get on your high horse as soon as anyone points out your mistakes.
|
|
|
|
|
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 <stdbool.h> which includes the macros
#define bool _Bool
#define true 1
#define false 0
In fact, in the comments to stdbool.h on my system I see
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.
modified 21-Feb-20 12:03pm.
|
|
|
|
|
k5054 wrote: NEAR and FAR pointers.
Oh the joys of the good old days. 
|
|
|
|
|
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.
|
|
|
|
|
I was also writing in assembler in those days so got used to near and far (and the pain it could cause).
|
|
|
|
|
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 )
|
|
|
|
|
_Bool is 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 a typedef). 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). The stdbool.h header 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 for unsigned char. However, if an implementation was to give _Bool the equivalent of unsigned 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 says
sizeof(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) = 8 but in 64 bit land
sizeof(int) = 4
sizeof(long) = 8
sizeof(long long) = 8
In 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 a struct tm currently has problems since struct tm defines 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 converting time_t to struct tm that's going to produce unexpected results based on "max value" of a time_t.
|
|
|
|
|
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.
|
|
|
|
|
Vaclav_ wrote: C and C++ -cannot AGREE
|
|
|
|
|
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)
{
}
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
modified 23-Feb-20 11:41am.
|
|
|
|
|
Yes, but he doesn't like being told.
|
|
|
|
|
... with only one exception:
if someone agrees with him! 
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
