In article <Couuyx.M4A@ses.com> jamshid@ses.com (Jamshid Afshar)
writes:

|> >Cast to a pointer to a
|> >private member class (Jamshid's example); the compiler will convert
|> >the two pointers implicitly to void*, and then you are back to my
|> >second example.

|> NO.  Comparisons between pointers to unrelated classes is a compile-
|> time error.

According to the current version of the working papers.

According to the ARM, it is not at all evident.  In fact, my reading
of the ARM would suggest that the compiler should convert both
pointers to void*, and then compare.

ARM, section 4.6, Pointer Conversions: "The following conversions may
be performed wherever pointers are assigned, initialized, compared, or
otherwise used....A pointer to any non-const and non-volatile object
may be converted to a void*."

In the version of the working papers that I have on line (not the
absolute latest), the second sentance has been expanded to allow
converting a const pointer to const void*, etc.

Although the above quote does not explicitly state that the
conversions referred to are implicite conversions, the list of
conversions includes the conversion of 0 to a pointer, and the
conversion of a pointer to a derived class to a pointer to the base
class.  I thus conclude that the paragraph is referring to implicite
conversions.

ARM, section 5.9, Relational Operators: "Pointer conversions are
performed on pointer operands."

As conversion to void* is explicitly one of the pointer conversions,
this would seem to imply that the compiler should convert both
pointers to void*, and compare the resulting pointers.

The working papers *have* clarified this: "Pointer conversions are
performed on pointer operands to bring them to the same type, which
must be a qualified or unqualified version of the type of one of the
operands."

So comparisons between unrelated pointer types is definitly a compile
time error according to the working papers.  But it is not something
that I would count on; the ARM can legitimatly be interpreted both
ways, and most compilers still implement the ARM, not the working
papers.  (Of the three compilers I have access to, two give an error,
and one core dumps.)

--
James Kanze                       email: kanze@lts.sel.alcatel.de
GABI Software, Sarl., 8 rue du Faisan, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                   -- Beratung in industrieller Datenverarbeitung

In article <ercCoII4w.Guo@netcom.com> erc@netcom.com writes:

   I haven't really been following this thread, but I'm wondering what
   will happen with function names.  I would like it to be an error to
   provide the name of a function that returns bool, instead of a call
   to that function, where type bool is wanted.

   For example:

   bool boolfunc();
   int intfunc();

   if(boolfunc) ... // Should be error.
   if(intfunc) ... // Should be allowed, for compatibility.

   Note that I am discussing bare function names, not calls.

in the examples above, what "if" sees is pointers to functions, of
the type:

 case 1: bool (*)()
 case 2: int (*)()

I don't really see why a pointer to a function returning bool should
make a difference.

--
!++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++!
! Richard Levitte, GNU on VMS hacker   ! tel: int+46-8-18 30 99            !
! Sulv"agen 57, II                     ! fax: none for the moment          !
! S-126 40 H"agersten                  ! Internet: levitte@e.kth.se        !
! SWEDEN                               !                                   !
!--------------------------------------------------------------------------!

In article <9404191728.AA04313@tdat.ElSegundoCA.NCR.COM>
swf@tdat.ElSegundoCA.NCR.COM (Stan Friesen) writes:

|> In article <KANZE.94Apr18171857@slsvhdt.us-es.sel.de>, kanze@us-es.sel.de (James Kanze) writes:
|> |> In article <Cnz3qx.K7J@world.std.com> miket@world.std.com (Michael
|> |> Trachtman) writes:

|> |> Using it as the type of a control expression is just icing on the
|> |> cake.  The real advantage will depend on the compiler writers; I would
|> |> hope any good compiler will now give a warning if the actual type of
|> |> the expression is *not* a bool.

|> If so, I would hope that this is switchable - I intend to keep using
|>  if (ptr)
|> style code, and would be very annoyed if it constantly gave me
|> warnings - that sort of spurious warning is what leads to people
|> routinely ignoring warnings (a dangerous situation).

|> |> |>      if (list) list.process();

|> |> As Jamshid Afshar has pointed out in another posting, `bool' will not
|> |> work for this.

|> Huh?  Why wouldn't "operator bool()" make this work?

I was too succinct.  Alone, in the quoted expression, it works.  But
in the original example, the type of the `list' object was a template.
The problem was, given the following code:

 List< int > l1 ;
 List< double > l2 ;

 if ( l1 == l2 ) ...

Declaring "operator bool()" makes the above if legal C++, although it
is obviously a typo.

However, on further though, I realize that all of the usual
alternatives (including Jamshid's) also make the above legal.  Cast
to "void*"; you can compare to void*'s.  Cast to a pointer to a
private member class (Jamshid's example); the compiler will convert
the two pointers implicitly to void*, and then you are back to my
second example.

Still another reason to not define conversion operators unless really
necessary.

--
James Kanze                       email: kanze@lts.sel.alcatel.de
GABI Software, Sarl., 8 rue du Faisan, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                   -- Beratung in industrieller Datenverarbeitung

In article <ercCon8AC.5p8@netcom.com>,  <erc@netcom.com> wrote:
>In article <9411116.19624@mulga.cs.mu.oz.au>,
>>It would also make it more difficult to write programs that output C++
>>source code.

It would be trivial to add a cast-to-bool to such output.

dag@control.lth.se (Dag Bruck) writes:

>I regret that the C++ standardization committee decided that saving
>three characters was worth more than giving this type the same name as
>in many other commonly used programming languages, e.g., Pascal,
>Modula-2 and Ada.  We did in fact vote on "bool" vs. "boolean".

But consistency dictates that it should be called "bool".
After all, we have "int" rather than "integer", and "char"
rather than "character".

--
Fergus Henderson - fjh@munta.cs.mu.oz.au

In article <2oh68uINNh5m@early-bird.think.com>, barmar@think.com (Barry Margolin) writes:

|> In article <Co4F06.EJ9@mv.mv.com> sdn@mv.mv.com (Eric Roode) writes:
|> >In article <Co2ILH.BnC@world.std.com>,
|> >Michael Trachtman <miket@world.std.com> wrote:
|> >>There are cases where the natural interpretation of List::operator int()
|> >>is not the correct one for putting into the if,while control expression.
|> >
|> >Well, then, I submit to you that creating a boolean class just so you
|> >can use <<if (list)>> instead of <<if (!list.empty())>> makes for MORE
|> >confusing and unreadable code than LESS.

[deleted]

|> >I thought of this. It seems to me that if there is a natural mapping
|> >of a class onto the set of ints, then it is terribly confusing to
|> >use the idiom <<if (x)>> -- boolean class or no.
|>
|> Why?  Perhaps there's a natural mapping of the class onto ints, and a
|> natural mapping of the class onto booleans, but different class values map
|> onto 0 and false.

There is already the case of pointers; the language defines that

 if (the_pointer)

is identical to

 if (the_pointer != NULL) // cf. !the_pointer.isNull() or !the_list.isEmpty()

even if NULL does not equal zero.  Therefore if one thinks of the pointer as
a class then it uses the operator bool() cast if it is used as a boolean and
its pointer stuff otherwise.  It may even have another operator: int() to
convert the pointer to an integer.

If there is a case for built-ins doing this then there is a case for user
defined classes to do it.  Perhaps for a string class?

Remember, not all classes have any meaning as an int (eg the string) so
does it make sense to cast it to an int?  In fact, if the string class
did have an int() cast that implements atoi() then by writing

  if (the_string)

we wouldn't mean

  if (atoi(the_string)==0),

we would mean

  if (the_string.exists())  // if (the_string != NULL)

If we disallow "if (the_string)" then existing code would be broken by the new
string class.

-----

Another reason for a bool class:

  on int:  --false => true    // --0 == -1
  on bool: --false => false

--
                    David P. Whipp.            <whipp@roborough.gpsemi.com>
Not speaking for:   -------------------------------------------------------
 G.E.C. Plessey     Due to transcription and transmission errors, the views
 Semiconductors     expressed here may not reflect even  my  own  opinions!

Seems it was imp@boulder.parcplace.com (Warner Losh) who said:
>P.S.  Has the appendix to the ARM been updated to include bool?  The
>last time I checked it hadn't been.

Yes, but the comment is extremely terse.  bool has been discussed in
much greater detail here.

--
Joseph Nathan Hall | Joseph's Law of Interface Design: Never give your users
Software Architect | a choice between the easy way and the right way.
Gorca Systems Inc. |                 joseph@joebloe.maple-shade.nj.us (home)
(on assignment)    | (602) 732-2549 (work)  Joseph_Hall-SC052C@email.mot.com

erc@netcom.com writes:

>I haven't really been following this thread, but I'm wondering what
>will happen with function names.  I would like it to be an error to
>provide the name of a function that returns bool, instead of a call
>to that function, where type bool is wanted.

I think making this an error would be a bad idea.  It would add yet
another special case rule, which would make the language more complex.
It would also make it more difficult to write programs that output C++
source code.

>I know it seems like it should be a warning rather than an error, but
>then some compiler vendors wouldn't bother, because they just want to
>sell compilers, not prevent bugs.

If you don't like their implementations, don't buy their compilers!

--
Fergus Henderson - fjh@munta.cs.mu.oz.au

In article <KANZE.94Apr22211019@slsvhdt.us-es.sel.de>,
James Kanze <kanze@us-es.sel.de> wrote:
>In article <9404191728.AA04313@tdat.ElSegundoCA.NCR.COM>
>swf@tdat.ElSegundoCA.NCR.COM (Stan Friesen) writes:
>> In article <KANZE.94Apr18171857@slsvhdt.us-es.sel.de>, kanze@us-es.sel.de (James Kanze) writes:
>>>>      if (list) list.process();
>>> As Jamshid Afshar has pointed out in another posting, `bool' will not
>>> work for this.
>> Huh?  Why wouldn't "operator bool()" make this work?
>
>I was too succinct.  Alone, in the quoted expression, it works.

I'll second this and clarify that I (Jamshid) did NOT ever say or imply
that List::operator bool() would not work as in the above expression.
The article which I believe James is referring to concluded that
user-defined conversions to bool are not one of the advantages of having
a real bool type.  In particular, I pointed out that conversions to a
Unique* is a much safer conversion than conversion to bool for class
templates.

>But in the original example, the type of the `list' object was a template.
>The problem was, given the following code:
>
> List< int > l1 ;
> List< double > l2 ;
> if ( l1 == l2 ) ...
>
>Declaring "operator bool()" makes the above if legal C++, although it
>is obviously a typo.

Right.

>However, on further though, I realize that all of the usual
>alternatives (including Jamshid's) also make the above legal.  Cast
>to "void*"; you can compare to void*'s.

You're right about void*'s.

>Cast to a pointer to a
>private member class (Jamshid's example); the compiler will convert
>the two pointers implicitly to void*, and then you are back to my
>second example.

NO.  Comparisons between pointers to unrelated classes is a compile-
time error.

 class Shape {};
 class Window {};

 class Ptr_Shape {
    class Unique {};
 public:
    operator Unique*();
 };

 class Ptr_Window {
    class Unique {};
 public:
    operator Unique*();
 };

 void bad_compare( Ptr_Shape s, Ptr_Window w ) {
    if (s==w)  // compile-time error: Ptr_Shape::Unique* and
       //...   //     Ptr_Window::Unique* are not compatible
 }

That's why I use this technique in any of my classes which emulate
pointers:

 template<class T> class Ptr {
    class Unique {};  // Ptr<T1>::Unique != Ptr<T2>::Unique
    T* ptr;
 public:
    operator const Unique*() const
       { return ptr ? (Unique*) ptr : 0; }
    friend int operator==(const Ptr<T>&, const Ptr<T>&);
    //...
 };

 void compare( Ptr<int> pi, Ptr<int> pj, Ptr<double> pd ) {
    if (pi && pj!=0 && !pd)  // okay
       if (pi==pj)             // okay
          if (pj==pd)          // compile-time error
          //...
 }

I do admit that if there were no operator==() defined, even converting
to Unique* would be error-prone because pi==pj would be legal.  In that
case I would probably declare, but not define, operator==() so that at
least the code is stopped at link time.  If I was really paranoid I
would declare the rest of the comparison operators and the minus
operator.

>Still another reason to not define conversion operators unless really
>necessary.

Well, I define conversion operators in my classes which emulate
pointers.  That includes my iterators, smart pointers (shared and
reference counting), and functors.  I like the way resulting user code
looks:

 class Textview { public: void scroll(double); };
 Textview tv;
 Functor1v<double> f;  // callback to any method taking a double
 if (...)
    f = functor(&tv, &Textview::scroll);
 //...
 if (f)
    f(0.5);

I do admit that figuring out how to best emulate pointers is difficult
because it's so easy to introduce overloading ambiguities.  Also, a lot
of current compilers fail to diagnose some ambiguity errors.  I believe
ANSI/ISO is still deciding some fine points about the ambiguity
resolution involving overloaded and built-in operators.

Is being able to write `if (f)' instead of `if (f.null())' worth the
trouble?  Hmm, for me it is, though I'd rather use f.null() instead of a
poorly done pointer-like class.

Jamshid Afshar
jamshid@ses.com

In article <Cnz3qx.K7J@world.std.com> miket@world.std.com (Michael
Trachtman) writes:

|> Eric Roode (sdn@mv.mv.com) wrote:
|> : Ah... maybe I'm missing something. Why is a boolean class desirable,
|> : or useful? What does it 'buy' me that a plain old C-style int doesn't?
|> : Thanks....

|> The real meat is the change in the type of the control expression
|> of an if, while, for etc.

The really important part is that the built-in comparison operators
return bool.  Thus, "f( a > b )" calls "f( bool )" and not "f( int )"
(supposing that both exists).  This was the one thing that could *not*
be emulated with a user defined class.

Using it as the type of a control expression is just icing on the
cake.  The real advantage will depend on the compiler writers; I would
hope any good compiler will now give a warning if the actual type of
the expression is *not* a bool.

|> Suppose I have a class X, and an instance x of X.
|> Suppose that there is an intuitive meaning for: if (x) { do_something(); }
|> then, how do I get that intuitive meaning to be evaluated.

|> The solution is to write a boolean conversion:

|>     operator boolean(X& x) { x.check_something() };

|> This allows the above if statement to work reasonably.

|> As a concrete example, if you have a class which represents a list,
|> then list.check_something() may tell you if the list is empty or not.
|> Using the boolean conversion operator would let you write:

|>      if (list) list.process();

As Jamshid Afshar has pointed out in another posting, `bool' will not
work for this.  (And as I pointed out, you shouldn't want it to.
IMHO, that.)
--
James Kanze                       email: kanze@lts.sel.alcatel.de
GABI Software, Sarl., 8 rue du Faisan, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                   -- Beratung in industrieller Datenverarbeitung

In article <KANZE.94Apr18171857@slsvhdt.us-es.sel.de>
kanze@us-es.sel.de (James Kanze) writes:
>As Jamshid Afshar has pointed out in another posting, `bool' will not
>work for this.  (And as I pointed out, you shouldn't want it to.
>IMHO, that.)

I'm curious about this statement and others I've seen in the group.

Will the following:
 if (x)
  foo();

try to convert "x", whatever it is, to a bool?  Or will it just be
another special case for if statements.  That is to say they will
retain the type they have, and if that is not zero, then foo will be
called?  bool is the result of the boolean operators (a < b) so in the
statement:
 if (a < b)
  bar();
the type of the expression for the if will happen to be bool, and the
compiler will know when those things are true and when they are false.
However, in the statement
 char *x
 if (x)
  bax();
the compiler will know the if "succeeded" because x is not zero, not
because there was a conversion to a bool type that turned out to be
true.

Is the above correct, or have I missed something along the way?  Is
this the reason that "if (list) list.process();" example won't work?

Slightly confused....

Warner

P.S.  Has the appendix to the ARM been updated to include bool?  The
last time I checked it hadn't been.
--
Warner Losh  imp@boulder.parcplace.COM ParcPlace Boulder
"... but I can't promote you to "Prima Donna" unless you demonstrate a few
 more serious personality disorders"

>>>>> "W" == Warner Losh <imp@boulder.parcplace.com> writes:

W> Will the following: if (x) foo();

W> try to convert "x", whatever it is, to a bool?

Yes.

W> However, in the
W> statement char *x if (x) bax(); the compiler will know the if
W> "succeeded" because x is not zero, not because there was a
W> conversion to a bool type that turned out to be true.

It will convert "x" to bool; in that conversion a zero pointer becomes
false and any other pointer becomes true.

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.

-- Dag

In article <DAG.94Apr19072354@bellman.control.lth.se>,
Dag Bruck <dag@control.lth.se> wrote:
>It will convert "x" to bool; in that conversion a zero pointer becomes
>false and any other pointer becomes true.

I haven't really been following this thread, but I'm wondering what
will happen with function names.  I would like it to be an error to
provide the name of a function that returns bool, instead of a call
to that function, where type bool is wanted.

For example:

bool boolfunc();
int intfunc();

if(boolfunc) ... // Should be error.
if(intfunc) ... // Should be allowed, for compatibility.

Note that I am discussing bare function names, not calls.

The reason for making this an error is very strong.  A bool function
with omitted function call parentheses is a bug which can cause
disastrous results and can remain hidden for years.

I know it seems like it should be a warning rather than an error, but
then some compiler vendors wouldn't bother, because they just want to
sell compilers, not prevent bugs.  But since bool is new, it can be
made an error without causing problems with old code.  Making it an
error will force all the compiler vendors to catch it.

In article <KANZE.94Apr18171857@slsvhdt.us-es.sel.de>, kanze@us-es.sel.de (James Kanze) writes:
|> In article <Cnz3qx.K7J@world.std.com> miket@world.std.com (Michael
|> Trachtman) writes:
|>
|> Using it as the type of a control expression is just icing on the
|> cake.  The real advantage will depend on the compiler writers; I would
|> hope any good compiler will now give a warning if the actual type of
|> the expression is *not* a bool.

If so, I would hope that this is switchable - I intend to keep using
 if (ptr)
style code, and would be very annoyed if it constantly gave me
warnings - that sort of spurious warning is what leads to people
routinely ignoring warnings (a dangerous situation).

|> |>      if (list) list.process();
|>
|> As Jamshid Afshar has pointed out in another posting, `bool' will not
|> work for this.

Huh?  Why wouldn't "operator bool()" make this work?

--
swf@elsegundoca.ncr.com  sarima@netcom.com

The peace of God be with you.

> mec@shell.portal.com (Michael Edward Chastain) writes:
>> I'm pleased that the committee has pushed this common data type
>> down into the base language.

>      Me too.  What spelling and capitalization did they use?

Thank you.  The new keywords are "bool", "false" and "true".

    -- Dag

mec@shell.portal.com (Michael Edward Chastain) writes:
>I'm pleased that the committee has pushed this common data type down
>into the base language.

     Me too.  What spelling and capitalization did they use?

      John Nagle

miket@world.std.com (Michael Trachtman) writes:

>My question is: Why is the type being called "boolean" instead of "bool"?

It's not.  The type will be called `bool'.

--
Fergus Henderson - fjh@munta.cs.mu.oz.au

Dag Bruck (dag@control.lth.se) wrote:
: >>>>> On Sat, 9 Apr 1994 03:47:21 GMT, miket@world.std.com (Michael Trachtman) said:


: Michael> My question is: Why is the type being called "boolean"
: Michael> instead of "bool"?

: The name of the type is "bool" (minus the quotes, of course).

: I pronounce it "boolean"; note that it is named after George Boole.

: I regret that the C++ standardization committee decided that saving
: three characters was worth more than giving this type the same name as
: in many other commonly used programming languages, e.g., Pascal,
: Modula-2 and Ada.  We did in fact vote on "bool" vs. "boolean".

I still don't see the usefulness.  If you want Ada, Modula-2, or
Pascal, well, you know where to find them.

--
"Insisting on perfect safety is for people who don't have the balls to live
 in the real world."   -- Mary Shafer, NASA Ames Dryden
------------------------------------------------------------------------------
Fred.McCall@dseg.ti.com - I don't speak for others and they don't speak for me.

In article <Co4F06.EJ9@mv.mv.com> sdn@mv.mv.com (Eric Roode) writes:
>In article <Co2ILH.BnC@world.std.com>,
>Michael Trachtman <miket@world.std.com> wrote:
>>There are cases where the natural interpretation of List::operator int()
>>is not the correct one for putting into the if,while control expression.
>
>Well, then, I submit to you that creating a boolean class just so you
>can use <<if (list)>> instead of <<if (!list.empty())>> makes for MORE
>confusing and unreadable code than LESS. :-)

That's a matter of opinion.  I think 'while (list) { /* do something */ }'
is quite readable; it's pretty obvious that the loop should continue as
long as the list has something in it.

But even if you're right, the boolean type would still be useful, as it
allows you to generate an error when the programmer tries to put a List in
the test of an if/while statement.  List::operator boolean() could be made
private to the class, so no clients could use it; it could signal an error
when invoked, to catch uses from within the class (is there a way to make
the conversion a compile-time error for class members as well?).

>>Or, there may be a few natural interpretations of operator int.
>>For example, in the case of a list with a built in iterator,
>>operator int() may convert the item being pointed to by the iterator
>>to an int. The bool operator may tell you if the list is empty.
>
>I thought of this. It seems to me that if there is a natural mapping
>of a class onto the set of ints, then it is terribly confusing to
>use the idiom <<if (x)>> -- boolean class or no.

Why?  Perhaps there's a natural mapping of the class onto ints, and a
natural mapping of the class onto booleans, but different class values map
onto 0 and false.
--
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar

In article <Cnz3uy.Ks4@world.std.com>, miket@world.std.com (Michael Trachtman) writes:
>
> My question is: Why is the type being called "boolean" instead of "bool"?
>

What are you talking about? The new type _is_ named 'bool'.

--
+==============================|==============================+
| 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: hwk@rational.com      |                              |
+==============================|==============================+

In article <Co81qr.5Io@megatest.com>, djones@megatest.com (Dave Jones) writes:
> From article <DAG.94Apr9173945@bellman.control.lth.se>, by dag@control.lth.se (Dag Bruck):
>
> > I regret that the C++ standardization committee decided that saving
> > three characters was worth more than giving this type the same name as
> > in many other commonly used programming languages, e.g., Pascal,
> > Modula-2 and Ada.  We did in fact vote on "bool" vs. "boolean".
> >
> >
> >      -- Dag
>
> My candidates would have been "Boole" and "Boolean".
>
> At least it should be capitalized, don't you think? It is a proper name,
> after all. Show a little respect.
>
>
>   - Dave
I think the decision to name it 'bool' was right. It is in the tradition of
C. We have "int" not "integer", "char" not "character", etc. So why should
we have "boolean"? Also, all fundamental types are written in lowercase. Why
should bool be different? Therefore, I think the committee in fact showed
respect with regard to the C/C++ tradition.

--
+==============================|==============================+
| 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: hwk@rational.com      |                              |
+==============================|==============================+

I have been reading in a couple of places that a boolean type will be added
to ANSI C++. However, my sources have not given any details, and I am
curious what is known about this proposed addition. Can anyone give any
examples of syntax or semantics? What is the name of the type?
Is it overloadable? Are there automatic conversions to/from int, or may
only a boolean be assigned to a boolean?

Any info would be appreciated. Email would be nice as well.

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)

Derek Foster (deef@teleport.com) wrote:
> I have been reading in a couple of places that a boolean type will be added
> to ANSI C++. However, my sources have not given any details, and I am
> curious what is known about this proposed addition. Can anyone give any
> examples of syntax or semantics? What is the name of the type?
> Is it overloadable? Are there automatic conversions to/from int, or may
> only a boolean be assigned to a boolean?

Actually, with C++ being type-safe etc... you simply create an new "type"
by defining a class.. The inconvenience is adding the .hpp file (and
.lib) to your make files...

But if you think about it... creating a boolean class should be straight
forward... you can use the smalling (char) defined type to hold its
value... Defining constructors to use the enums true/false on/off,
operators for = and == (do we all agree on < and > meanings ? <grin>)
Don't forget the operator << () for ostream stuff... Seems pretty
straight forward actually!

--
---------------------------------------------------
| Bob Zimmerman   bobzim@interaccess.com          |
|                                                 |
| If it's worth reading,                          |
|             you found it on Internet!           |
---------------------------------------------------

According D&E a boolean type (bool?) can be treated as an int so as not to
break existing code:

!0 -> bool of TRUE
0 -> bool of FALSE
bool of TRUE -> ( int ) 1
bool of FALSE -> ( int ) 0

Brian
--
+---------------------------------------------------------------+
| Brian Hook            | Specializing in real-time 3D graphics |
| Box 90315             |---------------------------------------|
| Gainesville, FL 32607 | Internet: bwh@cis.ufl.edu             |
+---------------------------------------------------------------+

Derek Foster (deef@teleport.com) wrote:
> I have been reading in a couple of places that a boolean type will be added
> to ANSI C++. However, my sources have not given any details, and I am
> curious what is known about this proposed addition. Can anyone give any
> examples of syntax or semantics? What is the name of the type?
> Is it overloadable? Are there automatic conversions to/from int, or may
> only a boolean be assigned to a boolean?

> Any info would be appreciated. Email would be nice as well.

I remember at one point seeing a post from a committee member which said
that the following definitions should make eventual conversion of code
as easy as possible:
    typedef int bool;
    static const bool false = 0;
    static const bool true = 1;

>>>>> On 2 Apr 1994 13:23:33 GMT, bobzim@interaccess.com (Bob Zimmerman) said:

Derek Foster (deef@teleport.com) wrote:
> What is the name of the type?
> Is it overloadable? Are there automatic conversions to/from int, or may
> only a boolean be assigned to a boolean?

A: "bool", yes, yes, no.

There is a section in Bjarne Stroustrup's "The Design and Evolution of
C++" with more explanation and examples.  Excellent book, by the way.

Bob> Actually, with C++ being type-safe etc... you simply create an
Bob> new "type" by defining a class... creating a boolean class should
Bob> be straight forward...

Actually, it isn't.  First, consider overloading, for example:

 class bool { /* .... */ };

 void f(int);
 void f(bool);

 int x;
 f(x < 3);

As the language is currently defined, the built-in operator < returns
an int, so f(x<3) falls f(int).  Defining your own boolean datatype
won't change that.  Consequently, you must change the existing
language (not only add a new type) to make overloading work with a
boolean type.

Second, there are several reasons (e.g., related to type conversions)
that lead to the conclusion that a boolean type should be a new
integral type instead of a class.

My recommendation is that you give up overloading until bool becomes a
built-in type in your compiler and define it as

 typedef int bool;
 const bool false = 0;
 const bool true = 1;

These definitions will make the transition to the "real" bool type
easy.

    -- Dag

Dag Bruck (dag@control.lth.se) wrote:
> >>>>> On 2 Apr 1994 13:23:33 GMT, bobzim@interaccess.com (Bob Zimmerman) said:

> Bob> Actually, with C++ being type-safe etc... you simply create an
> Bob> new "type" by defining a class... creating a boolean class should
> Bob> be straight forward...

> Actually, it isn't.  First, consider overloading, for example:
>  class bool { /* .... */ };
>  void f(int);
>  void f(bool);
>  int x;
>  f(x < 3);

> As the language is currently defined, the built-in operator < returns
> an int, so f(x<3) falls f(int).  Defining your own boolean datatype
> won't change that.  Consequently, you must change the existing
> language (not only add a new type) to make overloading work with a
> boolean type.

Hmmm. I think I am missing your point (no flame... having a brain f@rt
<grin>)... if I have a class called "myBool" and I create an object
called LightSwitch of that type... shouldn't that do all the things I
define.

myBool LightSwitch;

LightSwitch = myBool::on;

etc...

I am confused about your code... (I think I am talking apples and oranges
here)... I am interested though!!! Please explain (via email if you
choose). Thanks

--

---------------------------------------------------
| Bob Zimmerman   bobzim@interaccess.com          |
|        Voice:   (708) 402-4664                  |
|                                                 |
| If it's worth reading,                          |
|             you found it on Internet!           |
---------------------------------------------------

Dag Bruck (dag@control.lth.se) wrote:
>  class bool { /* .... */ };
>  void f(int);
>  void f(bool);
>  int x;
>  f(x < 3);

My brain f@rt just cleared up <grin>... I do understand now... but I
still believe if you simply define a boolean class, it can be used in
"overloading OTHER classes implementaions"... so that they can handle
it...

I absolutely agree that I would prefer the compiler to implement all this
effort... But in the work I have done, the class we have doesdo the job.

Thanks again...

--

---------------------------------------------------
| Bob Zimmerman   bobzim@interaccess.com          |
|        Voice:   (708) 402-4664                  |
|                                                 |
| If it's worth reading,                          |
|             you found it on Internet!           |
---------------------------------------------------

Ah... maybe I'm missing something. Why is a boolean class desirable,
or useful? What does it 'buy' me that a plain old C-style int doesn't?
Thanks....
--
----
Eric

"If anyone finds this offensive, I am prepared not only to retract my
words, but also to deny under oath that I ever said them." -- Tom Lehrer
----

Eric Roode (sdn@mv.mv.com) wrote:
: Ah... maybe I'm missing something. Why is a boolean class desirable,
: or useful? What does it 'buy' me that a plain old C-style int doesn't?
: Thanks....
: --
: ----
: Eric

: "If anyone finds this offensive, I am prepared not only to retract my
: words, but also to deny under oath that I ever said them." -- Tom Lehrer
: ----

The real meat is the change in the type of the control expression
of an if, while, for etc.


Suppose I have a class X, and an instance x of X.
Suppose that there is an intuitive meaning for: if (x) { do_something(); }
then, how do I get that intuitive meaning to be evaluated.

The solution is to write a boolean conversion:

    operator boolean(X& x) { x.check_something() };

This allows the above if statement to work reasonably.

As a concrete example, if you have a class which represents a list,
then list.check_something() may tell you if the list is empty or not.
Using the boolean conversion operator would let you write:

     if (list) list.process();

My question is: Why is the type being called "boolean" instead of "bool"?

The 'C' tradition is to use type names that truncate the full English
word. Thus we have 'int' instead of 'integer',
and 'char' instead of 'character'.
This is true for all 3 syllable type names.

Maybe, the writers of this proposal pronounce it using only two sylables:
i.e. "boo"-"lean".

>>>>> On Sat, 9 Apr 1994 03:47:21 GMT, miket@world.std.com (Michael Trachtman) said:


Michael> My question is: Why is the type being called "boolean"
Michael> instead of "bool"?

The name of the type is "bool" (minus the quotes, of course).

I pronounce it "boolean"; note that it is named after George Boole.

I regret that the C++ standardization committee decided that saving
three characters was worth more than giving this type the same name as
in many other commonly used programming languages, e.g., Pascal,
Modula-2 and Ada.  We did in fact vote on "bool" vs. "boolean".


     -- Dag

In article <Cnz3qx.K7J@world.std.com>,
Michael Trachtman <miket@world.std.com> wrote:
>Eric Roode (sdn@mv.mv.com) wrote:
>: Ah... maybe I'm missing something. Why is a boolean class desirable,
>: or useful? What does it 'buy' me that a plain old C-style int doesn't?
>: Thanks....
>
>Suppose I have a class X, and an instance x of X.
>Suppose that there is an intuitive meaning for: if (x) { do_something(); }
>then, how do I get that intuitive meaning to be evaluated.
>
>The solution is to write a boolean conversion:
>    operator boolean(X& x) { x.check_something() };
>This allows the above if statement to work reasonably.
>
>As a concrete example, if you have a class which represents a list,
>then list.check_something() may tell you if the list is empty or not.
>Using the boolean conversion operator would let you write:
>
>     if (list) list.process();

    Again, what does this buy me that  List::operator int()  doesn't?
--
----
Eric

"If anyone finds this offensive, I am prepared not only to retract my
words, but also to deny under oath that I ever said them." -- Tom Lehrer
----

In article <Co28Ay.5v4@mv.mv.com>, Eric Roode <sdn@mv.mv.com> wrote:
> Again, what does this buy me that  List::operator int()  doesn't?

If it doesn't buy you anything, you don't have to use it.

It buys _me_ an additional (small) measure of type correctness.
I like writing 'bool' for things that are either false or true.
I reserve 'int' for things that have cardinality.

My class library has its own implementation of boolean.  So does X11R5,
Motif 1.1.5, Interviews 3.1, Rogue Wave 6.0.2, and Gnu libg++ 2.5.3,
which are all the libraries I have here for examination.

I'm pleased that the committee has pushed this common data type down
into the base language.

Michael Chastain
mec@shell.portal.com

Eric Roode (sdn@mv.mv.com) wrote:
: In article <Cnz3qx.K7J@world.std.com>,
: Michael Trachtman <miket@world.std.com> wrote:
: >Eric Roode (sdn@mv.mv.com) wrote:
: >: Ah... maybe I'm missing something. Why is a boolean class desirable,
: >: or useful? What does it 'buy' me that a plain old C-style int doesn't?
: >: Thanks....
: >
: >Suppose I have a class X, and an instance x of X.
: >Suppose that there is an intuitive meaning for: if (x) { do_something(); }
: >then, how do I get that intuitive meaning to be evaluated.
: >
: >The solution is to write a boolean conversion:
: >    operator boolean(X& x) { x.check_something() };
: >This allows the above if statement to work reasonably.
: >
: >As a concrete example, if you have a class which represents a list,
: >then list.check_something() may tell you if the list is empty or not.
: >Using the boolean conversion operator would let you write:
: >
: >     if (list) list.process();

:     Again, what does this buy me that  List::operator int()  doesn't?
: --

There are cases where the natural interpretation of List::operator int()
is not the correct one for putting into the if,while control expression.

Or, there may be a few natural interpretations of operator int.
For example, in the case of a list with a built in iterator,
operator int() may convert the item being pointed to by the iterator
to an int. The bool operator may tell you if the list is empty.
This leads to idioms such as:

     List<int> x;
     int j;

     if (x)  j = x;

Note, than in this case, it is possible that the item stored in the list
is a 0. In this case, the if should still succeed. I.e. the above code
is different from:

      if (int(x)) j = x;

In summary, this approach recognizes that the control expression of
if,while,for  should be its own type, namely something that
evaluates to true or false.


I agree, its not a biggie:

Michael T.
miket@world.std.com

In article <Co28Ay.5v4@mv.mv.com> sdn@mv.mv.com (Eric Roode) writes:
>In article <Cnz3qx.K7J@world.std.com>,
>Michael Trachtman <miket@world.std.com> wrote:
>>The solution is to write a boolean conversion:
>>    operator boolean(X& x) { x.check_something() };
>>This allows the above if statement to work reasonably.

>    Again, what does this buy me that  List::operator int()  doesn't?

It allows you to use conversion to integer for something else, and the
false value of your type doesn't have to correspond to the value that
converts to the integer 0.  Assuming a list is "false" iff it's empty, your
version would work if List::operator int() returned the size of the list.
But suppose you wanted it to return the index of the newest element; in
that case, it would return 0 for a list with one element, and this wouldn't
make the boolean case work well.

--
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar

Redirected to c.l.c++.

In article <Co28Ay.5v4@mv.mv.com>, Eric Roode <sdn@mv.mv.com> wrote:
>In article <Cnz3qx.K7J@world.std.com>,
>Michael Trachtman <miket@world.std.com> wrote:
>>As a concrete example, if you have a class which represents a list,
>>then list.check_something() may tell you if the list is empty or not.
>>Using the boolean conversion operator would let you write:
>>
>>     if (list) list.process();
>
>    Again, what does this buy me that  List::operator int()  doesn't?

I believe the idea is that compilers will provide warnings for any
strange, probably unintended operations on bools like +,-,<, etc that
would otherwise go undiagnosed if you converted to int.  I agree with
this reasoning, but, what does `operator bool()' buy me that the
following convention doesn't:

 template<class T>
 class List {
    class Unique {};
 public:
    operator const Unique*() const
       { return empty() ? 0 : (const Unique*)this; }
    int empty() const;
    //...
 };

I can tell you what conversion to bool would cost me: the compiler
would allow a whole bunch of unintended operations between different
List types.

 void f( const List<int> i, const List<double> l ) {
    if (i==l)  // okay if convert to bool instead of Unique
       //...
 }
 void f( const Set<int> i, const Set<double> l ) {
    i += l;    // maybe warning for bool, but error for Unique
    if (i-l)   // maybe warning for bool, error for Unique
       //...     (okay, this last one is not a great example)
 }

Since I haven't seen the people behind the bool pushing `operator
bool()', I won't claim that bool is therefore useless.  They and
apparently a lot of other committee members feel the major advantages
of bool is the ability to overload and to reduce name conflicts
between libraries (though that doesn't help *existing* C++ programmers
with tons of scattered `#define bool char' or `typedef char bool' in
their and their libraries' headers).

I'm just curious if anyone has good reasons for converting to bool
instead of converting to a Unique*.

Jamshid Afshar
jamshid@ses.com

In article <Co2ILH.BnC@world.std.com>,
Michael Trachtman <miket@world.std.com> wrote:
>Eric Roode (sdn@mv.mv.com) wrote:
>: In article <Cnz3qx.K7J@world.std.com>,
>: Michael Trachtman <miket@world.std.com> wrote:
>: >Eric Roode (sdn@mv.mv.com) wrote:
>: >: Ah... maybe I'm missing something. Why is a boolean class desirable,
>: >: or useful? What does it 'buy' me that a plain old C-style int doesn't?
>: >: Thanks....
>: >
>: >Suppose I have a class X, and an instance x of X.
>: >Suppose that there is an intuitive meaning for: if (x) { do_something(); }
>: >then, how do I get that intuitive meaning to be evaluated.
>: >
>: >The solution is to write a boolean conversion:
>: >    operator boolean(X& x) { x.check_something() };
>: >This allows the above if statement to work reasonably.
>: >
>: >As a concrete example, if you have a class which represents a list,
>: >then list.check_something() may tell you if the list is empty or not.
>: >Using the boolean conversion operator would let you write:
>: >
>: >     if (list) list.process();
>
>:     Again, what does this buy me that  List::operator int()  doesn't?
>: --
>
>There are cases where the natural interpretation of List::operator int()
>is not the correct one for putting into the if,while control expression.

Well, then, I submit to you that creating a boolean class just so you
can use <<if (list)>> instead of <<if (!list.empty())>> makes for MORE
confusing and unreadable code than LESS. :-)

>Or, there may be a few natural interpretations of operator int.
>For example, in the case of a list with a built in iterator,
>operator int() may convert the item being pointed to by the iterator
>to an int. The bool operator may tell you if the list is empty.

I thought of this. It seems to me that if there is a natural mapping
of a class onto the set of ints, then it is terribly confusing to
use the idiom <<if (x)>> -- boolean class or no.

Just my two lincolns. Are you listening, ANSI? :-)  "Namespaces,
booleans, and localities, oh my!"

>[...]
>I agree, its not a biggie:

Absolutely -- despite my griping, I'm not getting terribly worked up
over this, but I do think that the ANSI committee is getting carried
away with itself.

>Michael T.
>miket@world.std.com


--
----
Eric

"If anyone finds this offensive, I am prepared not only to retract my
words, but also to deny under oath that I ever said them." -- Tom Lehrer
----