In article 95Jan11213018@colobus, bglenden@colobus (Brian Glendenning) writes:
>
>I know I used to know the answer to this -
>
>Why was a new integral (like) type made for bool, rather than making a
>bool class. I know something doesn't work with that, I just can't
>remember what! Thanks -

A boolean type works much better when built into the language instead of
being a library class. With a class, you can't get the fine-grained
control of automatic conversions that you really want.

Try writing your own boolean class that will behave as you would really
want. The design will collapse under its own weight before you get more
than a fraction of the desired behavior.

Making bool a built-in integer type allows it to fit into the language
neatly. The code you are used to writing still works. If you used your
own boolean typedefs or macros, you can probably make trivial source
changes, using 'bool', 'true' and 'false' without problems.

---
Steve Clamage, stephen.clamage@eng.sun.com

>>>>> "BG" == Brian Glendenning <bglenden@colobus> writes:

BG> Why was a new integral (like) type made for bool, rather than
BG> making a bool class. I know something doesn't work with that, I
BG> just can't remember what! Thanks -

C++ allows only one level of automatic user-defined conversion, plus
promotion.  If the conversion to bool was also a user-defined
conversion, some existing code would break (conversion to int isn't).


     -- Dag Bruck

In article <DAG.95Jan13083812@bellman.control.lth.se>, dag@control.lth.se (Dag Bruck) writes:
> >>>>> "BG" == Brian Glendenning <bglenden@colobus> writes:
>
> BG> Why was a new integral (like) type made for bool, rather than
> BG> making a bool class. I know something doesn't work with that, I
> BG> just can't remember what! Thanks -
>
> C++ allows only one level of automatic user-defined conversion, plus
> promotion.  If the conversion to bool was also a user-defined
> conversion, some existing code would break (conversion to int isn't).
>
>
>      -- Dag Bruck

In addition, operator&&, ||, etc. are normally short-circuited, i.e.,
they are evaluated from left to right until the result can be predicted.
For overloaded operators (e.g., for a boolean class), this is not true and all
arguments must be evaluated. Code that depends on this could break.
--
+==============================|==============================+
| Dr. Hartmut Kocher           |                              |
| Technical Consultant         | All opinions expressed here  |
| Rational GmbH                | are my own.                  |
| Rosenstrasse 7               |                              |
| 82049 Pullach im Isartal     | I know you guessed it,       |
| Germany                      | but it keeps my lawyer happy.|
| Email: kocher@lts.sel.alcatel.de                            |
+==============================|==============================+

In article 95Jan13083812@bellman.control.lth.se, dag@control.lth.se (Dag Bruck) writes:
>>>>>> "BG" == Brian Glendenning <bglenden@colobus> writes:
>
>BG> Why was a new integral (like) type made for bool, rather than
>BG> making a bool class. I know something doesn't work with that, I
>BG> just can't remember what! Thanks -
>
>C++ allows only one level of automatic user-defined conversion, plus
>promotion.  If the conversion to bool was also a user-defined
>conversion, some existing code would break (conversion to int isn't).

Andy Koenig also pointed out to me in private email that the result type
of comparison and logical operators should be boolean.  The built-in ones
cannot return a boolean type unless boolean itself is built-in.

---
Steve Clamage, stephen.clamage@eng.sun.com