Whats the point of bool?

[kid joe]

Hi all,

I know that from a C point of view, the bool or __Bool type was introduced
into C to standardize common practise in existing compilers, but from a
historical perspective does anyone understand what was the motivation for
languages like C++ and Java (and eventually C) to have a seperate type for
boolean variables instead of just using ints?

It seems pretty illogical to me, since I dont believe theres any common
hardware where individual bits can easily be addressed, so whats the gain
from having a type thats essentially an alias for int at the hardware
level, versus the added complexity for compiler writers and programmers?

Cheers,
Joe

 

[Keith Thompson]

I know that from a C point of view, the bool or __Bool type was introduced
into C to standardize common practise in existing compilers, but from a
historical perspective does anyone understand what was the motivation for
languages like C++ and Java (and eventually C) to have a seperate type for
boolean variables instead of just using ints?

It seems pretty illogical to me, since I dont believe theres any common
hardware where individual bits can easily be addressed, so whats the gain
from having a type thats essentially an alias for int at the hardware
level, versus the added complexity for compiler writers and programmers?

It's the same reason languages distinguish between integers and
floating-point numbers, for example. On the hardware level they're
both machine words; we just apply different operations to them. And
in fact one of C's ancestors (either B or BCPL, I don't remember
which) actually didn't make that distinction; it merely used different
operators for integer vs. floating-point addition and so forth.

It's for the benefit of the human reader. Declaring an object as
bool, or int, or double, lets the reader know what it's to be used
for, and lets the compiler generate the right code for it (or reject
operations that don't make sense).

In some languages that are more strongly-typed than C, you can't even
perform an "and" or "or" operation on integers, or "+" or "-" on
booleans. C is a lot looser, but it's still useful to be able to make
the distinction.

 

[chad]

It's the same reason languages distinguish between integers and
floating-point numbers, for example.  On the hardware level they're
both machine words; we just apply different operations to them.  And
in fact one of C's ancestors (either B or BCPL, I don't remember
which) actually didn't make that distinction; it merely used different
operators for integer vs. floating-point addition and so forth.

It's for the benefit of the human reader.  Declaring an object as
bool, or int, or double, lets the reader know what it's to be used
for, and lets the compiler generate the right code for it (or reject
operations that don't make sense).

In some languages that are more strongly-typed than C, you can't even
perform an "and" or "or" operation on integers, or "+" or "-" on
booleans.  C is a lot looser, but it's still useful to be able to make
the distinction.

Okay, at the risk of going off topic, what strongly-typed languages
can't peform "and" or "or" operations on integers, or "+" or "-" on
booleans? And more to the point. Why is this?

Chad

 

[BartC]

Okay, at the risk of going off topic, what strongly-typed languages
can't peform "and" or "or" operations on integers, or "+" or "-" on
booleans? And more to the point. Why is this?

You mean logical and/or rather than bitwise and/or?

And/or between integers require that those values are interpreted as true or
false, in other words as booleans. The language may prefer integers are used
for numerical values. C's interpretation that any non-zero value is true is
rather lax.

+ and - on booleans are not too sensible either: what's true-true or
true+false? What about true+1? Or False-56? The language may also prefer to
hide the actual values used for true and false.

 

[Keith Thompson]

Okay, at the risk of going off topic, what strongly-typed languages
can't peform "and" or "or" operations on integers, or "+" or "-" on
booleans? And more to the point. Why is this?

Pascal, for one; I'm sure there are plenty of others.

The reason is that, in the opinion of the designers of those
languages, those operations don't make sense. In Pascal, Boolean is a
distinct type; it's scalar, but it's not an integer type. Integer
values can't be used as conditions. A false value isn't denoted by
the number 0, it's denoted by False. An expression like (True + False),
or (10 and 20), just don't have any meaning in that context.

The designers of C chose a different model, with no strict separation
between integer values and boolean values.

 

[luserXtrog]

Okay, at the risk of going off topic, what strongly-typed languages
can't peform "and" or "or" operations on integers, or "+" or "-" on
booleans? And more to the point. Why is this?

You can't do it in Postscript, either.

 

[Phil Carmody]

A boolean is expected to be a type with two and only two possible
values.

Yup, but more than that though, the two possible values are expected
to represent the truth or falsity.

int bitOrder; // not expecting true/false, expecting HIGH2LOW or LOW2HIGH
int genderAtBirth; // not expecting true/false, expecting MALE or FEMALE

A variable called "city" is not expected to have one of two possible values.

It's far from uncommon that [noun] is used as a boolean variable
denoting the predicate 'is a [noun]'. Some more anal coding standards
might insist that such variables be named 'is[noun]' or suchlike,
but I'm sure they're in the minority.

Newbies to C do get confused on this issue and occasionally ask questions
about it in comp.lang.c.

Well, I'm glad to be able to assist one about such a matter.

Phil

 

[BartC]

Gordon Burditt said:

That's not even remotely strange. Consider: "Liverpool is a city" is
a true statement, and "Cabbage is a vegetable" is a true statement,
but the two statements are not equal to each other in any respect
other than their truth (or non-falsity if you prefer).

So? In C you can write:

int a=36, b=49;

if ( (a==36) == (b==49)) puts("A=36 and B=49 are both true");

It doesn't mean that a=36 and b=49 are equivalent.

The point was this;

if (a) puts("A is true");
if (b) puts("B is true");
if (a==b)
puts("A is the same as B");
else
puts("But A is not the same as B");

 

[Guest]

Okay, at the risk of going off topic, what strongly-typed languages
can't peform "and" or "or" operations on integers, or "+" or "-" on
booleans?

scheme can't perform addition on booleans

(+ #t #f)

Error: (+) bad argument type: #t

And more to the point. Why is this?

because it makes no sense. I remember a whole lecture devoted to the
axiomisation of boolean algebra (I only remember it because my
visceral
reaction was WHY, OH WHY!!) and they didn't include addition (ok, they
might have used the + symbol to mean "or").

sceme can perform "or" on integers but it might not
do what you expect.

(or 0 1)
0

(or 1 0)
1

It returns the first non-false item and both 0 and 1 are not-false.
I never knew that before...


--
Nick Keighley

The world you perceive is drastically simplified model of the real
world
(Herbert Simon)

 

[Chris Dollin]

wtf?!?

Depends of course on the context.

The context is Scheme ("sceme" is a typo, the name appeared untypoed
earlier in the post). Scheme follows the Lisp pattern where `(or A B ...)`
returns the value of the first non-false A B ...; whether or not you
think this overloading of the meaning of `or` is wise, it's certainly
a convenient operation to have. Scheme differs from traditional and Common
Lisp in that 'nil and the empty list are not false.

If you want to bit-diddle integers in a Lisp, you use the bit-diddling
functions of that Lisp. (I can't remember what they are and am too lazy
to look them up at the moment.)

 

[Eric Sosman]

Hi all,

I know that from a C point of view, the bool or __Bool type was introduced
into C to standardize common practise in existing compilers, but from a
historical perspective does anyone understand what was the motivation for
languages like C++ and Java (and eventually C) to have a seperate type for
boolean variables instead of just using ints?

An old joke tells of a citified society woman who visited
a farm and for the first time in her sheltered life witnessed
the operation of slopping the hogs. "Ugh!" said she, wrinkling
her well-bred nose in disgust, "No wonder they're called pigs!"

C uses zero and non-zero as surrogates for FALSE and TRUE.
This does not mean that FALSE and TRUE *are* zero and non-zero,
any more than Lisp's similar use of nil and non-nil mean that
nil *is* FALSE and non-nil *is* TRUE. Don't mistake the model
for the modeled.

It seems pretty illogical to me, since I dont believe theres any common
hardware where individual bits can easily be addressed, so whats the gain
from having a type thats essentially an alias for int at the hardware
level, versus the added complexity for compiler writers and programmers?

IMHO, _Bool adds little value to C. There is, however,
one subtlety you may have overlooked, which you might discover
by pondering this fragment:

typedef unsigned char myBool;
myBool x = 1073741824;
_Bool y = 1073741824;
if (x) puts ("x is true");
if (y) puts ("y is true");

See also "the !! operator."

 

[Anand Hariharan]

Gordon Burditt said:

There are times when I wish there was a physics programming
language which does dimensional and units checking:

Frink may meet your requirements.
(...)
[I do not give permission to quote any text from this article
without the source being properly attributed.]

With some leg-work, C++ can ensure dimensional consistency at compile
time:

http://se.inf.ethz.ch/~meyer/publications/OTHERS/scott_meyers/dimensions.pdf

- Anand

 

[Fred]

Gordon Burditt said:



Frink may meet your requirements.



That's not even remotely strange. Consider: "Liverpool is a city" is
a true statement, and "Cabbage is a vegetable" is a true statement,
but the two statements are not equal to each other in any respect
other than their truth (or non-falsity if you prefer).

<snip>

What I believe he means is that when a and b are both true,
one cannot simply check whether they are the same state:
if ( a == b ) {
/* both are the same state */
}
might give the wrong answer even if both are true.
So you have to resort to something like

if ( (a && b) || (!a && !b) )

 

[Keith Thompson]

So? In C you can write:

int a=36, b=49;

if ( (a==36) == (b==49)) puts("A=36 and B=49 are both true");

It doesn't mean that a=36 and b=49 are equivalent.

[...]

Using the same reasoning:

if ( 2+2 == 1+3) puts("2=2 and 1+3 have the same value");

It doesn't mean that 2+2 and 1+3 are equivalent.

But in fact it *does* mean they're equivalent; they both value the
value 4. "Equivalent" literally means "equal value".

Similarly a==36 and b==49 are equivalent. In C, they both have the
same value, 1, of type int. In a more strongly typed language, they
might both have the same value, True, of type Boolean (or however it's
spelled).

 

[Keith Thompson]

So? In C you can write:

int a=36, b=49;

if ( (a==36) == (b==49)) puts("A=36 and B=49 are both true");

It doesn't mean that a=36 and b=49 are equivalent.

[...]

Using the same reasoning:

if ( 2+2 == 1+3) puts("2=2 and 1+3 have the same value");

It doesn't mean that 2+2 and 1+3 are equivalent.

But in fact it *does* mean they're equivalent; they both have the
value 4. "Equivalent" literally means "equal value".

Similarly a==36 and b==49 are equivalent. In C, they both have the
same value, 1, of type int. In a more strongly typed language, they
might both have the same value, True, of type Boolean (or however it's
spelled).

[Sorry if this appears more than once; I tried to correct a typo just
as I was posting.]

 

[Andrew Poelstra]

Eric Sosman said:


I know. I don't know why, but I find the !! form preferable.

Probably the same reason folks prefer to have a bool type instead of int:
ease of programming. ! is read as "not", which is irrelevant to program
logic, whereas !! is read as "booleanize" (at least in my mind), which
expresses succinctly what you are trying to do.

 

[chad]

Or simply:

        if (!a == !b)

Is this De morgan's law at work?

 

[Keith Thompson]

Is this De morgan's law at work?

No.

De Morgan's laws are:

!(a || b) == !a && !b
!(a && b) == !a || !b

 

[chad]

No.

De Morgan's laws are:

    !(a || b) == !a && !b
    !(a && b) == !a || !b

Okay, I'm really not seeing how something like (!a == !b) equates to
both a and b being true.

 

[BartC]

Okay, I'm really not seeing how something like (!a == !b) equates to
both a and b being true.

It doesn't, it means they are both true or they are both false.