Tim Ottinger wrote:

> Being able to compare vs. true is intuitive to a lot of people who
> didn't learn from the people who taught you, or the people who taught
> me.
>

I guess I am just being old fashioned, and the more flexible one is
the more productive one becomes. Bool it is !

   RonD, rond@www-mail.huji.ac.il
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

RonD <rond@www-mail.huji.ac.il> wrote:
>
>>I am interested in the rationale for the bool type.
>>What was wrong with int ?

One of the main problems with int as boolean type is that you cannot
overload on both int the boolean type because they are identical.

Bool has to tightly integrated into the language because operators such
as == and && must return "bool".

Dag Bruck



[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

RonD wrote:
>
> I am interested in the rationale for the bool type.
> What was wrong with int ? Even ingnoring the heaps of existing
> (perfectly working) code which uses int -- how more intuitive can you
> get for 0=wrong, non 0 = false ???

How about 'false' and 'true'?

Actually, I had to debug newbie code enough times where you saw
this:
    #define TRUE 1
    #define FALSE 0

    x = fwrite(...);
    if ( x == TRUE )
    {
       // code you only reach if you write exactly one byte
    }
    else
    {
       // code executed normally whether it worked or not
    }


Being able to compare vs. true is intuitive to a lot of people who
didn't learn from the people who taught you, or the people who taught
me.

Then there's the situation where a lot of functions in Unix return
0 on success, or some other value on failure.  That makes some
sense, really, but doesn't fit the 'intuitive' true/false you are
defending.

The only problem that bool introduces in my sight is that it's only
binary state, so you have to get error codes some other way.  It's
a minor inconvenience, and everyone has a solution of one type or
another.
--
tim
+------------------------------------------------------------------+
|     Tell me again, *why* must we publish estimates before we     |
|     gather requirements?                                         |
+------------------------------------------------------------------+
| Tim Ottinger, Sr Tech        tottinge@csci.csc.com |
| CSC Communications Industry Services   217-351-8508x2420 |
| TRIS Division -- Cellular Billing and Support   Fax 217-351-2640 |
+------------------------------------------------------------------+
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

I am interested in the rationale for the bool type.
What was wrong with int ? Even ingnoring the heaps of existing
(perfectly working) code which uses int -- how more intuitive can you
get for 0=wrong, non 0 = false ???

 Ron Darziv, rond@www-mail.huji.ac.il


[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article C84@www-mail.huji.ac.il, Ron Darziv <rond@www-mail.huji.ac.il> writes:
>I am interested in the rationale for the bool type.
>What was wrong with int ? Even ingnoring the heaps of existing
>(perfectly working) code which uses int -- how more intuitive can you
>get for 0=wrong, non 0 = false ???

Maybe the typographical error in the last line answers your question. :-)

I suggest that if zero=false, non-zero=true seems intuitive, it is
because you have spent a lot of time learning that convention and
have internalized it. I programmed in languages which had true boolean
types before I learned C, and the C rule combined with a lack of a
boolean type seemed bizarre to me.

It is pretty common even in C programs to find something like
 typedef int bool;
 #define TRUE 1
 #define FALSE 0
If a bool type were unimportant, why would programmers bother with
typedefs and macros to simulate one? Because "bool", "true" and "false"
communicate unambiguously that a boolean condition is involved. When
you see int values that happen to be 0 or 1, it is not clear whether you
are looking at a boolean condition or a counter or something else.

The use of some sort of boolean simulation is so common in C and
especially C++ header files that you often find conflicting usage
that makes it impossible to include two particular headers in the
same program. If the standard provides a bool type, that conflict
is eliminated.
---
Steve Clamage, stephen.clamage@eng.sun.com




[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

RonD <rond@www-mail.huji.ac.il> wrote:

>I am interested in the rationale for the bool type.
>What was wrong with int ? Even ingnoring the heaps of existing
>(perfectly working) code which uses int -- how more intuitive can you
>get for 0=wrong, non 0 = false ???

The main problem with overloading int as the bool type is that it
doesn't work properly as a real boolean type with the == and !=
operators.

   int getbit( int f, int bit )  { return f & (1<<bit); }

   int main(void)
   {
      int f = 0x3;
      if(  getbit(f,0) == getbit(f,1) )
         cout << "bit 0 and bit 1 are the same" << endl;
   }

Also, consider what happen in the following on platforms where
sizeof(long) > sizeof(int):

  int main(void)
  {
      long f = 0x80000000L;
      int topbitset = f  &  (1L<<31);
      if(topbitset)
          cout << "top bit is set" << endl;
  }

Making bool a builtin type rather than a standard library class has a
lot to do with the fact that you cannot do short-circuit boolean
evaluation with an overloaded || and && operator.



---
Robert Mashlan  R2M Software  rmashlan@r2m.com
Internet Resources for Windows Developers http://www.r2m.com/windev/



[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Steve Clamage (clamage@taumet.eng.sun.com) wrote:
[Good stuff.]

Another issue. Lets say you want to have a boolean type that takes up less
space than an int. So you do the following:

typedef unsigned char boolean;

enum {
 false = 0,
 true = 1
};

Now the following code generates a warning under one compiler I use because
the call to testfunc truncates its argument:

void testfunc(boolean boolArg);
...
{
 testfunc(variable == 256);
}

Furthermore, idiomatic C would lead to:

{
 testfunc(variable);
}

Which is not what is intended.

I suppose one could claim the initial typedef is where the problem is and
one should not do that. If so, then why do I see exactly that done in so
many programs? (I.e. programmers aren't happy dedicating a whole int to
hold a bit in many places.)

-Z-
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

RonD <rond@www-mail.huji.ac.il> wrote:

>I am interested in the rationale for the bool type.
>What was wrong with int ? Even ingnoring the heaps of existing
>(perfectly working) code which uses int -- how more intuitive can you
>get for 0=wrong, non 0 = false ???

> Ron Darziv, rond@www-mail.huji.ac.il

One good reason is that with the bool type, you have the ability
to overload a function based on a bool type parameter. For eg:

void func(int arg);
void func(bool arg);

int main()
{
   int i, j;

   ...

   func(i);   // calls func(int arg);
   func(i < j);   // calls func(bool arg);
}

Hope that helps,

Rey Crisostomo
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

In article <323f57b8.6560013@library.airnews.net> rmashlan@r2m.com (Robert Mashlan) writes:
>    int getbit( int f, int bit )  { return f & (1<<bit); }

You're asking for trouble. Do this instead.
   int getbit( int f, int bit )  { return ((unsigned)f>>bit) & 1; }

> Also, consider what happen in the following on platforms where
> sizeof(long) > sizeof(int):
>
>   int main(void)
>   {
>       long f = 0x80000000L;
>       int topbitset = f  &  (1L<<31);
>       if(topbitset)
>           cout << "top bit is set" << endl;
>   }
>

First consider what happens when you assume there are 32 bits in either type.

 Jon Schneider
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

In article <323E37A4.C84@www-mail.huji.ac.il>, RonD <rond@www-mail.huji.ac.il> writes:
|> I am interested in the rationale for the bool type.
|> What was wrong with int ? Even ingnoring the heaps of existing
|> (perfectly working) code which uses int -- how more intuitive can you
|> get for 0=wrong, non 0 = false ???

I'd say that true==true and false==false is more intuitive.  If a function
returns an int is it really returning a number or is it returning
true/false?

Nearly every bit of significant C++ code I've seen went ahead and declared
an enum, some const ints, or did some #defines to add true/false,
True/False, or TRUE/FALSE.  Why not codify it into the language?

The lack of a true boolean type certainly wasn't fatal but having one is
a welcome addition.
--

- Bill Seurer     ID Tools and Compiler Development      IBM Rochester, MN
  Business: BillSeurer@vnet.ibm.com               Home: BillSeurer@aol.com
  WWW:  http://members.aol.com/BillSeurer
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Hi,
Steve Clamage (clamage@taumet.eng.sun.com) wrote:
: The use of some sort of boolean simulation is so common in C and
: especially C++ header files that you often find conflicting usage
: that makes it impossible to include two particular headers in the
: same program. If the standard provides a bool type, that conflict
: is eliminated.

I think, there is even more to it. Suppose, there is no type 'bool' in
C++. If you want to create a type, say 'boolean' which acts as a
boolean and accepts only the values 'true' and 'false' you have a
problem with the fact that normal operators return an 'int' rather than
a 'boolean' and there is no way around it. The problem shows up in the
presence of overloading:

  extern f(int);
  extern f(boolean);

  f(a < b);

'a < b' is clearly a boolean expression. But 'f(int)' would be called.
I think, this is very confusing, at least to programmers who are not
C++ experts.  Adding 'bool' to the language removed the need to write a
boolean class at all and also solves the overloading problem (unless
some people stick to the old style of returning 'int' from comparison
operators).
--
<mailto:dietmar.kuehl@uni-konstanz.de>
<http://www.informatik.uni-konstanz.de/~kuehl/>
I am a realistic optimist - that's why I appear to be slightly pessimistic
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]