int or bool?

[Fred]

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?

Thanks
Fred

 

[Chris Jefferson]

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).
Bools can in many ways be considered "almost the same as" ints where you
are only allowed 0 or 1, but they impose this condition for you rather
than forcing you to make sure you apply it yourself.

You can of course write functions and templates which behave differently
depending on which one they are given, but of course this is true for
all types.

Chris

 

[Ivan Vecerina]

Why was the bool type introduced into c++?

See for example:
http://www.gotw.ca/gotw/026.htm

What does it provide that int does not and are the two entirely
interchangable in conditional expressions?

bool only has two possible values/states: true and false.

Expressions such as a != b have a different meaning
for bool than for int.
When a and b are of bool type, it is equivalent to a logical x-or.

One should use bool whenever a value can only be true or false,
just as one should use int rather than double as it helps avoid
bugs.

hth,
Ivan

 

[Andrew Koenig]

Why was the bool type introduced into c++?

Because the practice of defining one's own synonym for int and using it as a
boolean type had grown to the point where large systems typically had
multiple incompatible definitions of boolean types.

What does it provide that int does not and are the two entirely
interchangable in conditional expressions?

They are not interchangeable. For one thing, if int and bool are different
types, you can overload on them.

 

[Dave O'Hearn]

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?

It was introduced because lots of code was creating its own bool types
and they were incompatible with each other. When done with macros, this
creates problems if two libraries try to define TRUE differently. With
enums in the global scope, it will fail to compile. Also, not everyone
made their "true" convertable to 1 like the standard does. Someone
might define "true" as -1, and then two different concepts of "true"
would compare unequal.

 

[jeffc]

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?

Using a number to represent a boolean was a hack to get around the fact that
there was no boolean. Kind of like using char* because there was no String
class.

 

[jeffc]

Because the practice of defining one's own synonym for int and using it as a
boolean type had grown to the point where large systems typically had
multiple incompatible definitions of boolean types.

Not to mention the fact that it required work to define and make available such
a basic type to begin with.

 

[Howard]

One should use bool whenever a value can only be true or false,
ok

just as one should use int rather than double as it helps avoid
bugs.

what? I'd think one should use int when integers are required, and double
when floating-point numbers are required (and when the float type is not
otherwise required for whatever reason). What does this have to do with
avoiding bugs?

-Howard

 

[Olivier Azeau]

what? I'd think one should use int when integers are required, and double
when floating-point numbers are required (and when the float type is not
otherwise required for whatever reason). What does this have to do with
avoiding bugs?

-Howard

Saying you can use an int to store a boolean value is like saying you
can use a double to store an int : you can do it but you can get a bug
for example if you store multiple values of the "bigger" set to
represent a single value of the "smaller" set.

bool a = true, b = true;
if( a && b )
assert( a == b ); // true

int a = -1, b = 1;
if( a && b )
assert( a == b ); // false

 

[Vinodh Kumar P]

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?

 

[Howard]

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

 

[chris]

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?

One thing to consider is that in some old systems, -1 was the "default"
way of representing true, because in 2s-complient (the most common way
of representing signed numbers in computers), -1 is represented by all
1's in binary. Therefore there is a good argument for -1 (at least)
being true.

Chris

 

[Mike Wahler]

They're interchangeable in a boolean context. But imo
type 'bool' and the keywords 'true' and 'false' more
clearly express intent.

TCPPPL says nonzero integers convert to true and 0 converts to false.
Correct.

Why all nonzero integers including negative integers should convert to

zero?

Because that's the way it is. "Zero" meaning "off", "clear", "false",
any other value meaning "on", "set", "true".

Boolean true/false means exactly two possible states. If zero
is 'false', any other value cannot mean 'false', because any
other number is not zero.

Converting negative integers to false is as natural as converting 0 to
false?

I don't think so.

True. False.
Zero. Not zero.

Simple.

-Mike