"Vinodh Kumar P" <pv**********@gmail.com> wrote in message
news:cp**********@news.mch.sbs.de...
"Chris Jefferson" <ca*@cs.york.ac.uk> wrote in message
news:41**************@cs.york.ac.uk... Fred wrote: > Why was the bool type introduced into c++?
> What does it provide that int does not and are the two entirely
> interchangable in conditional expressions?
>
First of all, I like bool because it lets me say what I mean. If I want
a function to return a "true" or "false" value, I make it return bool,
because that is exactly what I mean.
They are totally interchangable, because 1!=-1, but bool(1)==bool(-1).
TCPPPL says nonzero integers convert to true and 0 converts to false.
Why all nonzero integers including negative integers should convert to
zero?
Converting negative integers to false is as natural as converting 0 to
false?
In what way is a negative number false?
The main problem with doing something like that, as I see it, would be the
"accidental" use of a signed integer instead of an unsigned integer, and
then your "true" value of, say, 32768 would become a "false" value, with no
change to the actual value.
Is the following true or false?
if (128) {...
If the constant 128 is put into a signed 8-bit char, it's a negative number.
But put it in an unsigned char, or into a larger integer variable, and now
it's a positive number! See the problem? Suddenly context becomes
important, but whoever is reporting 128 (such as returning it from a
function) meant only true or false, not both!
The idea of zero being false is much more natural, also, since it is often
used when evaluating pointers (esp. pointers returned from functions). For
example, one often sees something like:
if (GetSomePointer()) {...
A poiinter is essentially an unsigned integer value, and when that value is
zero, it means the null pointer, which points to nothing, and is the only
valid condition that can be checked for to determine if you have a valid
pointer or not.
This idea has been extended to the function that returns an error code,
where 0 means it's ok, and anything else indicates a possible error
condition, so that you will see:
if (DoSomethingAndReportResults()) {...
This is much more undestandable than doing something like this:
if (DoSomethingAndReportResults() > 0) {...,
which is what would be *implied* if the integer value returned could be
interpreted as false when it was negative. Hiding that implied condition
would be a bad thing, in my opinion, and lead to many errors. It's much
easier to just know that if and only if a value is zero, testing it as a
boolean condition would return false.
That's my 2 cents worth, anyway.
-Howard
