In article <1994Apr26.181523.5085@vax1.mankato.msus.edu>,
Magnus G. Wissler <wiz@krypton.mankato.msus.edu> wrote:
>Nico Josuttis (nico@bredex.de) wrote:
>: Over the whole discussion it seems that people don't see the
>: main advantage of a type bool: readability.
>: In many, many C/C++ programs people design their own type bool,
>: like:
>
>[*chomp*]
>
>:  - enum bool { true, false}
>
>I see what you mean... If everybody designed their booleans that way, it sure
>would get difficult to read :)
>
>(just a silly thought ;)
>

You answer seems to say "that of course would no one do, how can you
give such examples" but believe me, it happens!
You don't believe? Want an example?

Take only the X Window System:
 - in the base lib "Xlib":
 in one file:
   #define BOOL long
 in another file:
   #define Bool int
 - in the lib above called the "X toolkit":
 #if NeedWidePrototypes
 #define _XtBoolean      int
 #else
 #define _XtBoolean      Boolean
 #endif
 ...
 #ifdef CRAY
 typedef long            Boolean;
 #else
 typedef char            Boolean;
 #endif
And now use X with C++:
 - in curses.h:
 #define bool char
 - in almost every class lib:
 class Boolean;
and now use another software with conflicting definitions
...
I hope you see now what i mean.

And the problem is not only the readability but the fact that
if you use two software libs with different definitions for
bool there occur naming conflicts or type conversion conflicts.

>/Magnus
(hope it now sound not as silly as you meant anymore)

--------
Nico                             address: BREDEX GmbH
email:   nico@bredex.de                   Nicolai Josuttis
                                          Fallersleber-Tor-Wall 23
phone:   +49 531 24330-0                  D-38100 Braunschweig
fax:     +49 531 24330-99                 Germany

In article <10252@bredex.de>, nico@bredex.de (Nico Josuttis) writes:
|>In article <1994Apr26.181523.5085@vax1.mankato.msus.edu>,
|>Magnus G. Wissler <wiz@krypton.mankato.msus.edu> wrote:
|>>Nico Josuttis (nico@bredex.de) wrote:
|>>: Over the whole discussion it seems that people don't see the
|>>: main advantage of a type bool: readability.
|>>: In many, many C/C++ programs people design their own type bool,
|>>: like:
|>>
|>>[*chomp*]
|>>
|>>:  - enum bool { true, false}
|>>
|>>I see what you mean... If everybody designed their booleans that way, it sure
|>>would get difficult to read :)
|>>
|>>(just a silly thought ;)
|>>
|>
|>You answer seems to say "that of course would no one do, how can you
|>give such examples" but believe me, it happens!
|>You don't believe? Want an example?
|>
|>Take only the X Window System:
|> - in the base lib "Xlib":
|> in one file:
|>   #define BOOL long
|> in another file:
|>   #define Bool int
|> - in the lib above called the "X toolkit":
|> #if NeedWidePrototypes
|> #define _XtBoolean      int
|> #else
|> #define _XtBoolean      Boolean
|> #endif
|> ...
|> #ifdef CRAY
|> typedef long            Boolean;
|> #else
|> typedef char            Boolean;
|> #endif
|>And now use X with C++:
|> - in curses.h:
|> #define bool char
|> - in almost every class lib:
|> class Boolean;
|>and now use another software with conflicting definitions
|>...
|>I hope you see now what i mean.
|>
|>And the problem is not only the readability but the fact that
|>if you use two software libs with different definitions for
|>bool there occur naming conflicts or type conversion conflicts.
|>
|>>/Magnus
|>(hope it now sound not as silly as you meant anymore)
|>
|>--------
|>Nico                             address: BREDEX GmbH
|>email:   nico@bredex.de                   Nicolai Josuttis
|>                                          Fallersleber-Tor-Wall 23
|>phone:   +49 531 24330-0                  D-38100 Braunschweig
|>fax:     +49 531 24330-99                 Germany
|>
|>

I believe Wissler was commenting on the fact that
the enum definition had true and false in the wrong order.

Mukesh Prasad (prasad@icpsrv.enet.dec.com) wrote:

[*chomp*]

: I believe Wissler was commenting on the fact that
: the enum definition had true and false in the wrong order.

Yup, I was, but Nico, I do see your point anyway, unless you actually intended
for the true and false to be in that order.

---
Magnus Wissler (wiz@krypton.mankato.msus.edu)

djones@megatest.com (Dave Jones) writes:

>From article <10234@bredex.de>, by nico@bredex.de (Nico Josuttis):
>> ... the main goal
>> in computer programming is readability.

>I didn't know that. Hmmm... I can see it now...

>Customer: Your new software deleted my disk drive and set my pants on fire!
>Me: Yeah, but it reads like a dream!

Customer: When will your software stop eating my bisquits?
You: I will ship a new release REAL_SOON_NOW.
(if i only knew what this code does)

  A boolean type offers the possibility of some more readability we should
use. On the other hand you can easily go on confusing code mintainers telling
them about tons of comments (may me a bit outdated, may be they don't want to
be distracted by telling about i and n beeing indices), using talking variable
names (ButUsuallyTheyAreTooLongToFitOnOneLineBecauseEverythingsGlobal). We all
could carry on like that. There is no such thing as automatic readability or
reuse or whatever. A language can help or even encurage us to strive towards
such aims, but we ourselfes are responsible to transform this into the code.

Peter
--
Peter Hahn                                                         Peterstr. 26
     52062 Aachen                                                Germany
          Peter@tequila.oche.de   pch@pool.informatik.rwth-aachen.de
                             Voice: +49 241 37151

In <DAG.94Apr27221053@bellman.control.lth.se> dag@control.lth.se (Dag Bruck) writes:

>>>>>> "Magnus" == Magnus G Wissler <wiz@krypton.mankato.msus.edu> writes:

>Magnus> : - enum bool { true, false}

>Magnus> I see what you mean... If everybody designed their booleans
>Magnus> that way, it sure would get difficult to read :)

Actually, it does get rather hard to read. If bool is defined as an enum (as
it is in the code I've been working with at work), people tend to go to
great lengths to try to avoid the explicit casts that are necessary when
converting, for instance, the zero-or-one results of comparison operators to
'bool' type. I often see code like:

   boolvar = (boolvar ? false : true);
   if ((x == y) ? false : true)
     return(somefunction());
   else
     return(false);

I think these are needlessly complex and error-prone, but I have been told
by coworkers they are "easier to understand" than:

    boolvar = !boolvar;
    return x!=y && somefunction();

Sigh.

Derek Riippa Foster
--
deef@teleport.com  Public Access User --- Not affiliated with TECHbooks
Public Access UNIX and Internet at (503) 220-0636 (1200/2400, N81)

In article <1994May2.092641.5356@vax1.mankato.msus.edu> wiz@krypton.mankato.msus.edu (Magnus G. Wissler) writes:
>Subject: Re: New ANSI C++ boolean type (readability!)
>From: wiz@krypton.mankato.msus.edu (Magnus G. Wissler)
>Date: 2 May 94 09:26:40 -0500

>Mukesh Prasad (prasad@icpsrv.enet.dec.com) wrote:

>[*chomp*]

>: I believe Wissler was commenting on the fact that
>: the enum definition had true and false in the wrong order.

>Yup, I was, but Nico, I do see your point anyway, unless you actually intended
>for the true and false to be in that order.


Stupid programmer tricks:

enum bool { true =0, false =42 };

Things like TRUE and FALSE aren't really integer values; code that depends
on the (arbitrary) value assigned to them is bad code.  I like, at some
point in a project, to redefine the values assigned to these kind of
variables, to see whose code still works, and whose comes crashing down
in a pile of rubble.

Of course, after all those years of C with no boolean type, it's become
acceptable to assume an integral value for true/false, as in:

if (someFlag) ...

but that doesn't mean I have to like it.

Over the whole discussion it seems that people don't see the
main advantage of a type bool: readability.
In many, many C/C++ programs people design their own type bool,
like:
 - typedef int bool
 - typedef int Bool
 - typedef int Boolean
 - typedef char bool
 - enum bool { true, false}
 - #define true 1
 - #define True 1
 - #define TRUE 1
 - class Boolean;
 - class bool;
 - ...
There are so many different definitions for such a fundamental type,
that it was absolutely necessary to define a standard for it.
And people, the fact that "int" works is fine, but the main goal
in computer programming is readability.

Due to the name of that type the discussion again seems a bit
rare: ALL keywords in C/C++ are only with small letters and it is a
general rule to give keywords not more chars than necessary,
so "bool" is exactly the goal.
Congratulations ANSI/ISO members (and please introduce "bool" also in C).

>W> P.S.  Has the appendix to the ARM been updated to include bool?
>W> The last time I checked it hadn't been.  -- Warner Losh
>
>There is a section in Bjarne Stroustrup's new book:
>
> The Design and Evolution of C++, Addison-Wesley, 1994.
>

For german people:
In my new book "Objektorietierte Programmierung in C++",
Addison-Wesley, 1994 I decided always to use "bool" for boolean
types, cause it is really more readable and easy to define
if compilers don't have it yet.

--------
Nico
                                 address: BREDEX GmbH
email:   nico@bredex.de                   Nicolai Josuttis
                                          Fallersleber-Tor-Wall 23
phone:   +49 531 24330-0                  D-38100 Braunschweig
fax:     +49 531 24330-99                 Germany
--------

>>>>> "Magnus" == Magnus G Wissler <wiz@krypton.mankato.msus.edu> writes:

Magnus> : - enum bool { true, false}

Magnus> I see what you mean... If everybody designed their booleans
Magnus> that way, it sure would get difficult to read :)

You have indeed spotted one of the main reasons for standardizing
"bool": there are quite a few incompatible definitions floating
around at present.

    -- Dag

Nico Josuttis (nico@bredex.de) wrote:
: Over the whole discussion it seems that people don't see the
: main advantage of a type bool: readability.
: In many, many C/C++ programs people design their own type bool,
: like:

[*chomp*]

:  - enum bool { true, false}

I see what you mean... If everybody designed their booleans that way, it sure
would get difficult to read :)

(just a silly thought ;)

/Magnus