In <comp.std.c++> ark@tempel.research.att.com (Andrew Koenig) writes:
>.....  If you
>want to take issue with something the committee has done and urge that
>they do something different, there is only one way to do so: show up at
>a committee meeting and argue your case in person.

At least you have to convince someone (e.g., your company's
representative) to argue for you, if you cannot go yourself.

    -- Dag

As part of the discussion about the real-world need to overload functions
on the basis of int and bool being different types, I opined that it was at
least desirable to have available both "operator int()" and "operator bool()".
Jamshid Afshar asked me to post an example.

Suppose I write a 64-bit integer class NationalDebtInt for a machine where the
largest built-in integer type is only 32 bits.  I would like this type to
integrate with, and mimic the behaviour of, the built-ins; so I provide
an "operator int()" that returns the low-order 32 bits.

Now, suppose a client writes:

 if ( myNationalDebtInt )
  cout << "Better raise taxes again";
 else
  cout << "Oh frabjous day!!";

If "operator int()" is used to evaluate the if-expression, then the test will
yield false if the low 32 bits are all zero, even if senior bits are on.  This
is an erroneous result. If an "operator bool()" were available, though, the
temporary euphoria and subsequent disappointment could be avoided.

-- Alan Waldock, from but not on behalf of Intel Corporation
   ajw@guardian.intel.com

<< I hadn't thought of saving away the original values of the flags and
then defining the constants to be something else.  That should work, but
would have to be very careful to make the change everywhere the flags are
used.  I would also have to set a hard rule that the original functions
I'm encapsulating can never be used from any of our code (since they would
expect the original values for G_ON and G_OFF).  At that point, though, I
don't know if we'd be any better off. >>

Look again: G_ON and G_OFF do have the original values!

Think of it this way, anyplace that used the C++ calls would have to
include the header. The header will redefine G_ON to be actually be
Flag::g_on. But Flag::g_on is enumerated to be equal to G_ON. Your C
library won't know the difference, only the trick C++ function can
tell it isn't the same. You can freely mix calls of your C++
function with the raw C library calls, no problem.

The only caution you would need is not to use true/false with the
raw C calls (which is a problem regardless).

If you still don't believe me, try my example code again with the
TEST macro defined like this:

#define TEST(value) \
    cout<<"setFlag(" #value ")= "<<setFlag(value)<<endl\
        <<"gSetFlay(" #value ")= "<<gSetFlag(value)<<endl

What do you think now?

--
---------------------------------------------------------
Robin Rowe    Rowe Techology | Flamers and complainers:
rrowe@halcyon.com            |  If you have nothing to
Northwest C++ Users Group    |   contribute please don't.

Sorry if you're seeing more than once; our news is a bit flaky right now.

In article <HAYDENS.94Jan18175744@wayback.atc.ll.mit.edu>,
Hayden Schultz x3685  <haydens@ll.mit.edu> wrote:
>>> On 15 Jan 1994 18:48:49 GMT, tmb@arolla.idiap.ch (Thomas M. Breuel) said:
>Thomas> So why is "bool" any different than "List<T>", "Array<T>", "vector",
>Thomas> "matrix", "Graph", etc.?  Those class names also frequently cause name
>Thomas> conflicts and semantic conflicts between independently developed
>Thomas> libraries.
>
>My understanding of namespaces is incomplete, since I've only read
>remarks about the proposal, and not the proposal itself. [I'd be
>grateful if someone would post or email the proposal]

You can ftp the latest ANSI Resolutions appendix for CPL2 and the ARM
from world.std.com in the directory AW/stroustrup2e.

>But my understanding is that namespaces will handle class name conflicts,
>but not typedef or #defined conflicts.

Namespaces will handle all non-preprocessing identifiers: class names,
typedef names, functions names, global variable names, etc.

>So if someone does (and they do)
>#define bool   unsigned int

Correct, namespaces wouldn't help here.  Then again, neither would a
built-in bool.  Especially if bool is #defined to char, which I do see
very often.  I've been (unpleasantly) surprised at how many C and C++
packages define or typedef bool as a char (trn, cppp, curses,
zip/unzip).

Even if the compiler implements bool as an int and the bad header
#define's bool to int, you would still run into lots of errors at
link-time because of type-safe linking.

Jamshid Afshar
jamshid@ses.com

In article <HAYDENS.94Jan18175744@wayback.atc.ll.mit.edu>,
Hayden Schultz x3685  <haydens@ll.mit.edu> wrote:
>>> On 15 Jan 1994 18:48:49 GMT, tmb@arolla.idiap.ch (Thomas M. Breuel) said:
>Thomas> So why is "bool" any different than "List<T>", "Array<T>", "vector",
>Thomas> "matrix", "Graph", etc.?  Those class names also frequently cause name
>Thomas> conflicts and semantic conflicts between independently developed
>Thomas> libraries.
>
>My understanding of namespaces is incomplete, since I've only read
>remarks about the proposal, and not the proposal itself. [I'd be
>grateful if someone would post or email the proposal]

You can ftp the latest ANSI Resolutions appendix for CPL2 and the ARM
from world.std.com in the directory AW/stroustrup2e.

>But my understanding is that namespaces will handle class name conflicts,
>but not typedef or #defined conflicts.

Namespaces will handle all non-preprocessing identifiers: class names,
typedef names, functions names, global variable names, etc.

>So if someone does (and they do)
>#define bool unsigned int

Correct, namespaces wouldn't help here.  Then again, neither would a
built-in bool.  Especially if bool is #defined to char, which I do see
very often.  I've been (unpleasantly) surprised at how many C and C++
packages define or typedef bool as a char (trn, cppp, curses,
zip/unzip).

Even if the compiler implements bool as an int and the bad header
#define's bool to int, you would still run into lots of errors at
link-time because of type-safe linking.

Jamshid Afshar
jamshid@ses.com

Reply To: Alan Waldock ajw@ornews.intel.com (Thu Jan 20 16:54:27
PST 1994)

<< Suppose I write a 64-bit integer class NationalDebtInt for a
machine where the largest built-in integer type is only 32 bits.
I would like this type to integrate with, and mimic the behaviour
of, the built-ins; so I provide an "operator int()" that returns
the low-order 32 bits.

If "operator int()" is used to evaluate the if-expression, then
the test will yield false if the low 32 bits are all zero, even if
senior bits are on.  This is an erroneous result. If an "operator
bool()" were available....>>

Thank you for your example.

I would certainly agree it is an erroneous result. In fact, isn't
your operator int() too dangerous to use at all in the financial
application you gave as your code example? Wouldn't any financial
institution using your Int64 class be very unhappy that large
values are transparently changed into zero when converted to int?

Wouldn't any programmer maintaining your code be greatly surprised
and perhaps alarmed to find bool(number) > abs(int(number)) for
lots of values besides INT_MIN?

However, let's say that you chose a different application that for
some reason really needed just the low 32 bits sometimes (maybe a
hardware thing). Wouldn't you want the high part sometimes, too?
Doesn't an explicit call of number.Low32(), and number.High32(),
make more sense in any real situation than blithely hoping
operator int() will handle things correctly? (Portability problems
due to byte ordering aside.)

What do you think?

Robin
--
-------------------------------------------------------
Robin Rowe    Rowe Techology | Flamers and complainers:
rrowe@halcyon.com            |  If you have nothing to
Northwest C++ Users Group    |   contribute please don't.

In article <2hntfp$1p1@nwfocus.wa.com> rrowe@halcyon.com (Robin Rowe) writes:
>Reply To: Alan Waldock ajw@ornews.intel.com (Thu Jan 20 16:54:27
>PST 1994)
>
..><< Suppose I write a 64-bit integer class NationalDebtInt for a
..>machine where the largest built-in integer type is only 32 bits.
..>I would like this type to integrate with, and mimic the behaviour
..>of, the built-ins; so I provide an "operator int()" that returns
..>the low-order 32 bits.
..>
..>If "operator int()" is used to evaluate the if-expression, then
..>the test will yield false if the low 32 bits are all zero, even if
..>senior bits are on.  This is an erroneous result. If an "operator
..>bool()" were available....>>
>
>Thank you for your example.
>
>I would certainly agree it is an erroneous result. In fact, isn't
>your operator int() too dangerous to use at all in the financial
>application you gave as your code example? Wouldn't any financial
>institution using your Int64 class be very unhappy that large
>values are transparently changed into zero when converted to int?

Yes, probably; they'd be equally unhappy that large-valued longs
become zero when converted to a short and they've got warnings turned
off.  Look, it was a top-of-the head example of when operator int()
and operator bool() might need to do different things, not a suggestion
for a World Bank programming paradigm.

>Wouldn't any programmer maintaining your code be greatly surprised
>and perhaps alarmed to find bool(number) > abs(int(number)) for
>lots of values besides INT_MIN?

>However, let's say that you chose a different application that for
>some reason really needed just the low 32 bits sometimes (maybe a
>hardware thing).

No, not a hardware thing. My example class is supposed to be interminglable
with shorts, ints, longs; there HAS to be a cast.

>                 Wouldn't you want the high part sometimes, too?
>Doesn't an explicit call of number.Low32(), and number.High32(),
>make more sense in any real situation than blithely hoping
>operator int() will handle things correctly? (Portability problems
>due to byte ordering aside.)

When I *actually* wrote my *real* Int8, I provided no cast; users have
to code "myInt8.low32Bits()"  and  "(myInt8>>32).low32Bits()" to extract
the component parts. I did this reluctantly, but I was motivated to do it
because of the "if (myInt8)" problem I described, not because of possible
loss of precision.  (And there are no portability problems - byte ordering
is taken care of by the compiler, n'est-ce pas?)

Anyway, as I said, it was just an example. I can't believe that practically
anyone who reads this newsgroup couldn't come up with another. Look at
your own classes that already have a cast-to-int or a cast-to-pointer;
aren't there cases where being able to use an object name as a boolean
expression (perhaps for state, like iostreams) would be desireable?

>Robin
>--


-- Alan Waldock, from but not on behalf of Intel Corporation
   ajw@guardian.intel.com

In article <rfgCJCsGy.IpD@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:
>If `bool' (or any other "late" extension) is really that great, then why not
>just wait for Borland, Microsoft, USL, IBM, and everyone else to add it
>to their compilers on their own?  Why force it down everyone's throat by
>making it a required part of the base standard?

Because they are all likely to do it differently.  This is one of the
reasons that the ANSI Pascal committee sunk in cement boots - by the
time the standardization effort got started many desirable extensions
(and Pascal needed several significant ones to be useful) had
been implemented by vendors, including me (Oregon Software).  Users
had in some cases large investments in code using those extensions.
Getting agreement in the standard meant either 1) picking an
existing implementation, causing potential financial harm for
others with competing implementatinos or 2) making a "neutral"
extension (i.e. different from any vendor's).  The politics just
sunk any reasonable efforts (this is just part of the story,
as Wirth, unlike Strastroup, was unwilling to take a leadership
role in standardization).

This is an IDEAL time to add such extensions, while there is still
hope for compatible implementations.  I am concerned about the
committee's rather large suitcase of (in some cases) complicated
extensions, but I simply do not see how anyone can get a hair up
their a** about something as simple as boolean.

In article <CJs1FL.MA1@microsoft.com> jimad@microsoft.com (Jim Adcock) writes:

> So then, programs that assume "0" and "1" on output aren't going to
> format right anymore?

If compatibility is an issue, the default locale can print "1" or "0".

> And what pray tell, does the preposal say about these issues?

Nothing -- which means that in the absence of other proposals, printing
a bool quietly converts it to an int.

Adopting the bool proposal makes it possible for the Library working
group to decide how they want to handle bool values, if at all.
--
    --Andrew Koenig
      ark@research.att.com

In article <HAYDENS.94Jan14115222@wayback.atc.ll.mit.edu> haydens@ll.mit.edu writes:

> I think it's more important to consider the reader of the code rather
> than the writer of the code. if(p != NULL) indicates to the reader
> that p is being used like a pointer. if(p) means that the reader has
> to know a lot more about the type p before it's really understood.

If I know the purpose of a variable, I usually know its type too --
or at least I know enough about its type to understand the contexts in
which I see it used.
--
    --Andrew Koenig
      ark@research.att.com

In article <CJL4J4.5x9@microsoft.com> jimad@microsoft.com (Jim Adcock) writes:

> You guys need to do the work entailed in making a serious proposal,
> so that others can correctly judge the merit [or lack thereof]
> in your proposal.

Not true.  Dag and I made a proposal, the committee voted to accept it, and
that ends the matter.

While various members of the committee, as a courtesy to the C++ community,
spend considerable time and energy discussing the committee's work, those
discussions are purely informative and carry no official weight.  If you
want to take issue with something the committee has done and urge that
they do something different, there is only one way to do so: show up at
a committee meeting and argue your case in person.
--
    --Andrew Koenig
      ark@research.att.com

In article <rfgCJo3us.3Cq@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:
>In article <FST.93Dec31115100@nimo.claircom.com> fst@nimo.claircom.com (Fariborz Skip Tavakkolian) writes:
>>In article <rfgCIsF44.D7D@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:
>>
>>>  There is an old saying that a camel is a horse which was designed
>>>  by committee.
>>>  It seems particularly apropos in this context.
>>
>>Are you suggesting that camels are bad?  For those of us who are from
>>that part of the world, this is a very sensitive issue :-)
>
>Oh!  You mean Southern California? :-)

I had suspected you were a comedian...  Now I know. :-)

>>In a previous posting you suggested that language is becoming
>>experimental (``designed in a lab'').  Could someone name a
>>concept in the language (C++) that does not exist in another
>>(predecessor) language?
>
>Incrementing booleans.

This exists in C, as in:

typedef int boolean;
boolean x_was_seen = 0; /* Use x_was_seen to represent a logic state */
...
if (! x_was_seen) x_was_seen++;

More accurately, both the concept of a Boolean type, and the concept
of applying the increment (++) operator to such a boolean type have
existed in C, at least as an idiom.
(my point is that the ``idea'' existed and has been practiced)

Is the following any stranger?

char a;
for (a = 'A'; a <= 'I'; a++) /* Philosophically, what does a++ mean? */
  {
    printf("%c.", a);
  }

Incrementing values of boolean type would not be an aberration.

>-- Ronald F. Guilmette, Sunnyvale, California -------------------------------
>------ domain address: rfg@netcom.com ---------------------------------------
>------ uucp address: ...!uunet!netcom.com!rfg -------------------------------

Fariborz
--
--
    ********************************************************************
    *  Fariborz ``Skip'' Tavakkolian Claircom Communications Group  *
    *  fst@claircom.com   700 Fifth Ave, Suite 2100      *
    *  (206)389-7150   Seattle, WA.  98104            *
    ********************************************************************

In article <2h4e6e$pg4@senator-bedfellow.MIT.EDU> jfc@ATHENA.MIT.EDU (John F Carr) writes:
|In article <trickr.45.0010524A@uh2372p03.daytonoh.ncr.com>,
|Ralph Trickey <trickr@uh2372p03.daytonoh.ncr.com> wrote:
|
|>I can't see throwing the English words True and False into the iostream
|>library
|
|If the C++ standard follows the C standard, "true" and "false" could change
|according to the locale.

So then, programs that assume "0" and "1" on output aren't going to
format right anymore?  I had thought the output would change to
"T" and "F" so at least the formatting would remain the same, but
I guess this wouldn't work in all locales?  If for instance, "true"
and "false" were the correct outputs, then does one have to type
"true" and "false" on input to read in a bool?  And thus a bool by
default takes 4 or 5 bytes to store in a file?  Or does input at least
still accept "0" and "1" as a backwards compatibility sop?  Further,
should "yes" and "no" be accepted to mean true and false on input
[or their suitable locale equivalents] ?

And what pray tell, does the preposal say about these issues?

>>>>> On 15 Jan 1994 18:48:49 GMT, tmb@arolla.idiap.ch (Thomas M. Breuel) said:
Thomas> So why is "bool" any different than "List<T>", "Array<T>", "vector",
Thomas> "matrix", "Graph", etc.?  Those class names also frequently cause name
Thomas> conflicts and semantic conflicts between independently developed
Thomas> libraries.

My understanding of namespaces is incomplete, since I've only read
remarks about the proposal, and not the proposal itself. [I'd be
grateful if someone would post or email the proposal] But my
understanding is that namespaces will handle class name conflicts, but
not typedef or #defined conflicts.

So if someone does (and they do)

#define bool unsigned int

or

typedef unsigned char bool;

then you're hosed. I'm tired of being hosed.

If you were to say that a standard library class "bool" would do 90%
of what I want, I'd agree with you. I like having a boolean type, and
really appreciate a standard. Basically bool and int do not mean the
same thing.

 Hayden
--
Hayden Schultz
haydens@ll.mit.edu
MIT Lincoln Lab
244 Wood St.
Lexington, MA, 02173
(617) 981-3685

alby@uunet.uu.net (Anthony Williams @ UUNET Technologies Inc, Falls Church, VA, USA)

 > On a slightly more technical note, I would consider a plethora of
 > incompatable language extentions to be a very large failure in the
 > standardization efforts.

So would I. So would any sensible person.

 - Bjarne

The
 if (p) ...

idiom will remain legal.

it is NOT implementation dependent. It means that p is compared to the 0-pointer
whatever the 0-pointer's value may be.

In article <2h1sm0INN67s@umbc7.umbc.edu> squire@umbc.edu (Mr. Jon S. Squire) writes:

> But, but, but! You do not seem to understand that null pointers may be
> non zero. This is implementation dependent, as every 'coder' should
> understand.

Regardless of representation, every null pointer is required to compare
equal to (literal integral) zero.
--
    --Andrew Koenig
      ark@research.att.com

As to where the egregious idiom of incrementing "boolean" flags comes
from, I present the following excerpt (w/o permission):

GETOPT(3)              C LIBRARY FUNCTIONS              GETOPT(3)

NAME
     getopt, optarg, optind - get  option  letter  from  argument
     vector

[...]

EXAMPLE
     The following code fragment shows how one might process  the
     arguments for a command that can take the mutually exclusive
     options a and b, and the option o, which requires an  option
     argument:

          main(argc, argv)
          int argc;
          char **argv;
          {
               int c;

Sun Release 4.1    Last change: 6 October 1987                  1

GETOPT(3)              C LIBRARY FUNCTIONS              GETOPT(3)

               extern char *optarg;
               extern int optind;
               .
               .
               .
               while ((c = getopt(argc, argv, "abo:")) != -1)
                    switch (c) {
                    case 'a':
                         if (bflg)
                              errflg++;
                         else
                              aflg++;
                         break;
                    case 'b':
                         if (aflg)
                              errflg++;
                         else
                              bproc ();
                         break;

[...]

<sigh>


--
Joseph Nathan Hall | Well, my address just gets worse and worse looking.
Software Architect |
Gorca Systems Inc. |                 joseph@joebloe.maple-shade.nj.us (home)
(on assignment)    | (602) 732-2549 (work)  Joseph_Hall_SC052C@email.mot.com

I wasn't saying that cout<<char(27) is the best way, only that for
those who do find this sort of thing important it is trivial to work
around. If you want to discuss style, following your lead I would do
this:

 const bool STATUS=(a==b);
 cout<<STATUS;

I don't think that cout<<bool compares to cout<<char. It
isn't that common for one thing. For another, outputting 1 or 0 is
the logical response (which int does already) unless you want some
non-portable behavior such as English "true"/"false".

Robin

--
---------------------------------------------------------
Robin Rowe    Rowe Techology | Flamers and complainers:
rrowe@halcyon.com            |  If you have nothing to
Northwest C++ Users Group    |   contribute please don't.

In article <2h4e6e$pg4@senator-bedfellow.MIT.EDU> jfc@ATHENA.MIT.EDU (John F Carr) writes:
>In article <trickr.45.0010524A@uh2372p03.daytonoh.ncr.com>,
>Ralph Trickey <trickr@uh2372p03.daytonoh.ncr.com> wrote:

>>I can't see throwing the English words True and False into the iostream
>>library

>If the C++ standard follows the C standard, "true" and "false" could change
>according to the locale.

Isn't the locale defined by the operating system. Is it really likely that any
of the OS's will make the necessary changes to implement bools?

Ralph Trickey

<<OK...  I'm using a graphics package written in C which has a number of
functions for setting flags and such, where the calling convention is to
pass G_ON or G_OFF as the argument to turn the flag on or off, respectively.
I can't be sure of the numeric values of G_ON and G_OFF, so I can't just
assume the default int->bool conversion will work.  Instead, I want to
say:
 ...
 void setFlag(bool val=true)
 {  gSetFlag(val ? G_ON : G_OFF);
 }
 void setFlag(int val=G_ON)
 {  gSetFlag(val);
 }
>>

You can make it work right with just one function if you write a
small helper class. No need for this to have a bool type that I
can see. Here is the code to do it:

#include <iostream.h>

//#define REVERSED  // Test this both ways!
#ifdef REVERSED
#   define G_ON  0
#   define G_OFF 1
#else
#   define G_ON  1
#   define G_OFF 0
#endif

const int false=0; // I chose this representation at random,
const int true=!false; // not a political statement.

class Flag // Helper class for type conversion.
{   int flag;
public:
    enum FLAG {g_off=G_OFF,g_on=G_ON};
    Flag(FLAG flag)
    :    flag(flag)
    {}
 Flag(int tf)
    :    flag(tf ? G_ON : G_OFF)
    {}
    operator int()
    {    return flag;
}   };

#undef G_ON
#undef G_OFF
#define G_ON  Flag::g_on
#define G_OFF Flag::g_off

int gSetFlag(int value) // this is just a dummy for testing.
{   return value;
}

inline int setFlag(Flag value)
{   return gSetFlag(value);
}

// A macro to save some typing in my test program:
#define TEST(value) \
 cout<<"setFlag(" #value ")= "<<setFlag(value)<<endl

int main()
{   cout<<"*** Testing setFlag() ***\n";
#ifdef REVERSED
    cout<<"REVERSED";
#else
    cout<<"Normal";
#endif
    cout<<" output\n"
        <<"#define G_ON  "<<G_ON<<endl
 <<"#define G_OFF "<<G_OFF<<endl;
    TEST(G_ON);
    TEST(G_OFF);
    TEST(true);
    TEST(false);
    return 0;
}

/* output

*** Testing setFlag() ***
REVERSED output:
#define G_ON  0
#define G_OFF 1
setFlag(G_ON)= 0
setFlag(G_OFF)= 1
setFlag(true)= 0
setFlag(false)= 1
*** Testing setFlag() ***
Normal output:
#define G_ON  1
#define G_OFF 0
setFlag(G_ON)= 1
setFlag(G_OFF)= 0
setFlag(true)= 1
setFlag(false)= 0
*/

What do you think?

Robin
--
---------------------------------------------------------
Robin Rowe    Rowe Techology | Flamers and complainers:
rrowe@halcyon.com            |  If you have nothing to
Northwest C++ Users Group    |   contribute please don't.

In article <2hl4g3$i6n@nwfocus.wa.com>, Robin Rowe <rrowe@halcyon.com> wrote:
><<OK...  I'm using a graphics package written in C which has a number of
>functions for setting flags and such, where the calling convention is to
>pass G_ON or G_OFF as the argument to turn the flag on or off, respectively.
>I can't be sure of the numeric values of G_ON and G_OFF, so I can't just
>assume the default int->bool conversion will work.  Instead, I want to
>say:
> ...
> void setFlag(bool val=true)
> {  gSetFlag(val ? G_ON : G_OFF);
> }
> void setFlag(int val=G_ON)
> {  gSetFlag(val);
> }
>>>
>
>You can make it work right with just one function if you write a
>small helper class. No need for this to have a bool type that I
>can see. Here is the code to do it:
...

This is the critical piece of your code:

>class Flag {
...
>  public:
>    enum FLAG { g_on=G_ON, g_off=G_OFF }
...
>}
>
>#undef G_ON
>#undef G_OFF
>#define G_ON  Flag::g_on
>#define G_OFF Flag::g_off

I hadn't thought of saving away the original values of the flags and
then defining the constants to be something else.  That should work, but
would have to be very careful to make the change everywhere the flags are
used.  I would also have to set a hard rule that the original functions
I'm encapsulating can never be used from any of our code (since they would
expect the original values for G_ON and G_OFF).  At that point, though, I don't
know if we'd be any better off...

- Brad
------------------------------------------------------------------------
+ Brad Daniels                  | "Let others praise ancient times;    +
+ Biles and Associates          |  I am glad I was born in these."     +
+ These are my views, not B&A's |           - Ovid (43 B.C. - 17 A.D.) +
------------------------------------------------------------------------

In article <FST.93Dec31115100@nimo.claircom.com> fst@nimo.claircom.com (Fariborz Skip Tavakkolian) writes:
>In article <rfgCIsF44.D7D@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:
>
>>  There is an old saying that a camel is a horse which was designed
>>  by committee.
>>  It seems particularly apropos in this context.
>
>Are you suggesting that camels are bad?  For those of us who are from
>that part of the world, this is a very sensitive issue :-)

Oh!  You mean Southern California? :-)

>In a previous posting you suggested that language is becoming
>experimental (``designed in a lab'').  Could someone name a
>concept in the language (C++) that does not exist in another
>(predecessor) language?

Incrementing booleans.

--

-- Ronald F. Guilmette, Sunnyvale, California -------------------------------
------ domain address: rfg@netcom.com ---------------------------------------
------ uucp address: ...!uunet!netcom.com!rfg -------------------------------

rrowe@halcyon.com (Robin Rowe) writes:

>Is there a bool class that is considered state-of-the-art short
>of a compiler extension? It would help me to be clearer if I
>could see exactly where defining a standard bool.h library is
>inadequate.

The following is considered the best that you can do without
a compiler extension:

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

--
Fergus Henderson        |   "People who brook no compromise in programming
                        |   languages should program in lambda calculus or
fjh@munta.cs.mu.OZ.AU   |   machine language, depending." --Andrew Koenig.

In article <HAYDENS.94Jan14121931@wayback.atc.ll.mit.edu>, haydens@wayback.atc.ll.mit.edu (Hayden Schultz x3685 ) writes:
|> The biggest reason [for putting a bool type into the standard] I find is constructors.
|>
|> class A {
|>   A(int);
|>   A(bool);
|> };
|>
|> To do this now, I've got to either typedef bool to a non int, make an
|> enum, or a class. And whatever I choose, it's going to conflict with
|> anyone who uses the name bool and makes a different decision. The most
|> frustrating case of all is when I use two existing libraries which
|> each use two different solutions for bool-- then it's not my fault at
|> all.

So why is "bool" any different than "List<T>", "Array<T>", "vector",
"matrix", "Graph", etc.?  Those class names also frequently cause name
conflicts and semantic conflicts between independently developed
libraries.

     Thomas.

Your example bool.h code seems a bit crude to me. No offense intended.
You helped me understand the discussion better by showing it. Does
everyone agree that this is the best we can do?

Robin
--
---------------------------------------------------------
Robin Rowe    Rowe Techology | Flamers and complainers:
rrowe@halcyon.com            |  If you have nothing to
Northwest C++ Users Group    |   contribute please don't.

How about this:

 cout<<bool(x==y)<<endl;

This seems like a trivial task, and no different from things we
do now such as cout<<char(27);.

Robin

--
---------------------------------------------------------
Robin Rowe    Rowe Techology | Flamers and complainers:
rrowe@halcyon.com            |  If you have nothing to
Northwest C++ Users Group    |   contribute please don't.

I don't understand. Why is the feature of f(bool) worth a language
extension?

Robin

--
---------------------------------------------------------
Robin Rowe    Rowe Techology | Flamers and complainers:
rrowe@halcyon.com            |  If you have nothing to
Northwest C++ Users Group    |   contribute please don't.

What does your Object(bool) constructor do that is different from
your Object(int) constructor? I am having trouble imagining a real
use for the example you gave.

Robin

--
---------------------------------------------------------
Robin Rowe    Rowe Techology | Flamers and complainers:
rrowe@halcyon.com            |  If you have nothing to
Northwest C++ Users Group    |   contribute please don't.

In article <2gs9me$hll@nic.lth.se> dag@control.lth.se (Dag Bruck) writes:
|The key question is: do you want "x > 3" to return bool?  If the
|answer is yes, you must change the basic language.

I disagree.  Rather the key question is:

1)if you want "x > 3" to return bool and
2)if you can identify precisely what changes should be make to the language
3)and if there is agreement that these are the "best" possible changes
4)and if making those changes is better overall than not making the changes
THEN you must change the basic language.

Your and Koenig's proposal breaks down at stage #2 -- you have not
precisely identified the changes you are proposing to make to the
language.  Followed by #3 -- you have not done the competitive analysis
against other reasonable implementation choices for 'bool' to indicate
that your proposal [whatever it really is] is better than the other
available choices.

You guys need to do the work entailed in making a serious proposal,
so that others can correctly judge the merit [or lack thereof]
in your proposal.

In article <trickr.45.0010524A@uh2372p03.daytonoh.ncr.com>,
Ralph Trickey <trickr@uh2372p03.daytonoh.ncr.com> wrote:
>In article <MATT.94Jan10193824@physics2.berkeley.edu> matt@physics2.berkeley.edu (Matt Austern) writes:
>>There are a few places where you can tell the difference between these
>>two possibilities, but not all that many.  The most obvious is if
>>you've defined both f(int) and f(bool), and you call f(3<4).
>
>I keep seeing this asan argument for bool being a built-in type instead of in
>the standard library, and I haveto wonder why would anyone want to? Why would
>I want a function that accepts either ints or bools and behaves differently?
>I can't see throwing the English words True and False into the iostream
>library, sothe only logical things for it to print are 0 and 1 anyway because
>they were converted to int. I tendto overload the meaning of bool anyway so I
>want different things printed for each variable anyway, sometimes Yes/No or
>Male/Female or .....

I completely agree -- I've never wanted to output out a boolean value
as the strings "true" or "false".  Can someone provide actual examples
where they wanted to overload a function on bool?

Another advantage of built-in bool that I've seen mentioned is that
automatic conversions to bool is safer than converting to int.  I
agree, but is converting to bool safer than the technique I use in my
smart pointer classes: conversion to `const Unique*'?

 template<class T>
 class SmartPtr {
    class Unique {};
    T* p;
 public:
    //...
    operator const Unique*() const
       { return p ? (const Unique*)p : 0; }
    friend int operator==(const SmartPtr&,const SmartPtr&);
 };
 void foo(SmartPtr<int> i, SmartPtr<double> d) {
    if (i==d) ... // compile-time error
 }

If SmartPtr<T> instead converted to a bool, the code would compile
fine.  Are the any advantages of conversion to bool that my technique
doesn't have?

>The only other use that I can see is to allow a collection class to compact
>bools insteadof storing them as ints. Even then I don't see where having bool
>defined as a built-in type makes things any easier.

I agree.  A (possibly standard) bitset class will solve this problem,
though.

>So, can anyone tell me why I would WANT to overload bool?
>I am not against bool as a built-in type, I want all the type-checking I can
>get, and I think compilers will be eventually be able to do better
>type-checking with bool as a built-in type, I just get sick of hearing
>overloading as a reason for bool being a built-in type.

I guess I could live with and use a "converting bool to int" warning,
but I would definitely turn off any "converting pointer/int to bool"
warnings because I don't think common, recommended, and standard C/C++
code like:

 if (p) /*...*/

should be changed.

I don't even understand the argument that having one built-in `bool'
type fixes the existing problem of multiple definitions.  Defining a
standard `bool' does not magically make all those definitions in
/usr/include or any other C headers disappear or work easily.  For
example, my curses.h #defines bool it as a char, so built-in bool
doesn't help me at all to use curses.h.  As for existing and future
class libraries, weren't namespaces invented to solve this problem?

Jamshid Afshar
jamshid@ses.com

In <comp.std.c++> jimad@microsoft.com (Jim Adcock) writes:
>
>Your and Koenig's proposal breaks down at stage #2 -- you have not
>precisely identified the changes you are proposing to make to the
>language.

I think the description was precise enough, although it did not
consist of a listing of verbatim changes to the working paper.  You
disagree, and I'm certain some members of the standardization
committee also do.  However, the majority of the committee found that
it was good enough.

>Followed by #3 -- you have not done the competitive analysis
>against other reasonable implementation choices for 'bool' to indicate
>that your proposal [whatever it really is] is better than the other
>available choices.

Well, we did analyze

 - bool defined as class
 - bool defined as enum
 - bool typedef'd to int
 - do nothing (i.e., described the current problems)

That seems to me like a reasonable number of analyzed choices.  Maybe
you do not think the analysis was good enough?  That is a different
issue, and you are obviously entitled to think that our work is no
good.

At full committee (not working group) I received one comment
specifically on the quality of the proposal, and that person claimed
that the proposal good enough to judge it.  I can also mention that
the person voted against the proposal, but I'm happy it was a
well-informed decision.  (I have decided not to mention any name; the
person reads netnews and can step forward if he so pleases.)


     -- Dag

In article <trickr.45.0010524A@uh2372p03.daytonoh.ncr.com> trickr@uh2372p03.daytonoh.ncr.com (Ralph Trickey) writes:
>In article <MATT.94Jan10193824@physics2.berkeley.edu> matt@physics2.berkeley.edu (Matt Austern) writes:
>>In article <CJFp16.EHJ@tempel.research.att.com> ark@tempel.research.att.com
>(Andrew Koenig) writes:
>
>>> > What would happen if the bool type was part of a standard library
>>> > instead of a built-in type?
>>>
>>> Then it would be hard to understand how the type of expressions
>>> like 3<4 could be expressed.
>
>>Not *that* hard.  Expressions like 3<4 would continue to return ints,
...
>
...
>. I tend to overload the meaning of bool anyway so I
>want different things printed for each variable anyway, sometimes Yes/No or
>Male/Female or .....
>
Ah, a user for:

bool enum answer{Yes, No}; //(I would have made it "No, Yes")
bool enum female{Male, Female);

Chris Perrott

In article <758228582.28snx@beorn.ping.dk> hclausen@beorn.ping.dk (Henrik Clausen) writes:
>In article <BRUCE.94Jan10151044@cmsr3.liverpool.ac.uk> bruce@liverpool.ac.uk writes:
>>> [cperrott, actually...]
>>> Why not introduce keyword 'bool' with the same status as 'signed'? Why not
>>> allow:
>>
>>> bool b; //int is implicit
>
>   Nah. int's usually take 4 bytes, where just one bit is needed. Wasteful.
Happy to see that the point about control of storage size got across. My idea
was that int would probably be the type that allowed the fastest processing,
even if it took quite a lot of memory, and therefore having 'bool b;' declare
as much storage as 'int b;' would be reasonable.
>
>>> bool long b4; //Well, maybe I want to add all the true flags to a long int> sum!
>
>>I don't see what "bool int", "bool char", etc., are supposed to mean.
>>As far as I can see, they are meaningless.  As meaningless as char int.
>
>   Packed bit arrays? Interesting idea at the language level, quite useful for
>real low-level, I/O-register-orientated programming, drivers and stuff.
>
Unfortunately, C++ doesn't yet have the capability to deal with bits. As I
understand it, the smallest unit it can deal with is a char, which will be
a byte if you're lucky. It does allow for bit fields within a struct, but
does not define them well enough to allow the development of portable
software using bit fields.

I would be happy with a definition that allowed the programmer to have control
over storage down to the byte level, for now. Let's worry about the bit level
some other time.

Chris Perrott

In article <FST.93Dec31115100@nimo.claircom.com> fst@nimo.claircom.com (Fariborz Skip Tavakkolian) writes:

>In a previous posting you suggested that language is becoming
>experimental (``designed in a lab'').  Could someone name a
>concept in the language (C++) that does not exist in another
>(predecessor) language?

You have inverted the sense of the experiment.

The operative question is this one: can you name a concept in another
language that does not exist in C++?

(:

-Luddy Harrison

rrowe@halcyon.com (Robin Rowe) writes:

>How about this:
>
> cout<<bool(x==y)<<endl;
>
>This seems like a trivial task, and no different from things we
>do now such as cout<<char(27);.

You do?  I personally use something like

 #define ESC '\033'
 ...
 cout << ESC;

The C++ language used to do the wrong thing for

 cout << 'a';

but this has since changed.  I think that it is good
that C++ will one day (when my compiler implements the new bool type)
do the "right" thing for

 cout << (a == b);

--
Fergus Henderson        |   "People who brook no compromise in programming
                        |   languages should program in lambda calculus or
fjh@munta.cs.mu.OZ.AU   |   machine language, depending." --Andrew Koenig.

In article <CJMyw2.AF2@ses.com>, Jamshid Afshar <jamshid@ses.com> wrote:
>I completely agree -- I've never wanted to output out a boolean value
>as the strings "true" or "false".  Can someone provide actual examples
>where they wanted to overload a function on bool?

OK...  I'm using a graphics package written in C which has a number of
functions for setting flags and such, where the calling convention is to
pass G_ON or G_OFF as the argument to turn the flag on or off, respectively.
I can't be sure of the numeric values of G_ON and G_OFF, so I can't just
assume the default int->bool conversion will work.  Instead, I want to
say:

    ...

    void setFlag(bool val=true) { gSetFlag(val?G_ON:G_OFF); }
    void setFlag(int val=G_ON) { gSetFlag(val); }

    ...

This is a real example from my code, though the function names have been
changed to protect third party vendors...

- Brad
------------------------------------------------------------------------
+ Brad Daniels                  | "Let others praise ancient times;    +
+ Biles and Associates          |  I am glad I was born in these."     +
+ These are my views, not B&A's |           - Ovid (43 B.C. - 17 A.D.) +
------------------------------------------------------------------------

fst@nimo.claircom.com (Fariborz Skip Tavakkolian) writes:
| In a previous posting you suggested that language is becoming
| experimental (``designed in a lab'').  Could someone name a
| concept in the language (C++) that does not exist in another
| (predecessor) language?

harrison@sp10.csrd.uiuc.edu (Luddy Harrison) writes:
>You have inverted the sense of the experiment.
>The operative question is this one: can you name a concept in another
>language that does not exist in C++?

Garbage collection.

Actually there are many others: go beyond the algol-like and OO languages
and consider functional and dataflow languages, logic programming,
parallel languages, and so forth, not to mention visual languages, and
you'll find tons of concepts not found in C++.  I mentioned garbage
collection since it is present in many of the languages C++ most directly
competes with (Smalltalk, Modula-3).


--
-- Joe Buck jbuck@synopsys.com
Posting from but not speaking for Synopsys, Inc.
Formerly jbuck@<various-hosts>.eecs.berkeley.edu

In article <CJMyw2.AF2@ses.com> jamshid@ses.com (Jamshid Afshar) writes:

>                                  Can someone provide actual examples
>where they wanted to overload a function on bool?

There are cases when one needs to differentiate between operator int()
and operator bool() -- does that count?

-- Alan Waldock, from but not on behalf of Intel Corporation
   ajw@guardian.intel.com

ark@tempel.research.att.com (Andrew Koenig <9577-82971> 059113A) writes:

>A significant fraction of the C community is not interested in object-oriented
>programming.  Indeed, some of them would rather see C++ go away entirely.
>For example, the C standards committee has begun work on the next version
>of the C standard; it is likely that it will go in quite a
>different direction from C++.

Hmmm. Two questions:

 1. Would you care to elaborate on the likely path of divergence?

 2. If such a divergence does occur, will it be possible to maintain
    (near) backward compatibility with C? Will C++ have had the rug
    pulled out from under its feet? Or do you envisage (and welcome?) C++
    eventually becoming less "C-ish"?

damian
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  who: Damian Conway                 email: damian@bruce.cs.monash.edu.au
where: Dept. Computer Science        phone: +61-3-565-5184
       Monash University               fax: +61-3-565-5146
       Clayton 3168                  quote: "A pessimist is never disappointed."
       AUSTRALIA

In article <2gduag$e08@nic.lth.se> dag@control.lth.se (Dag Bruck) writes:
|In <comp.std.c++> jimad@microsoft.com (Jim Adcock) writes:
|>
|>As a strawman counterproposal, how about if we bite the bullet, have a
|>'real' bool type WITHOUT the implicit coercion back from int to bool,
....
|It's hardly a strawman, because that is what Andy and I originally
|proposed (and the committee changed).  If anyone would like to propose
|a change back to the original proposal, that's fine with me and I will
|support it.

Well, this points out a couple more problems I have with your and
Koenig's proposal, namely:

* The proposal DOES NOT do any of the competing-alternatives analysis
that Koenig claims is required before adding any extensions to the
language.  For example your proposal ought to evaluate the advantages
disadvantages of making ++ and int->bool deprecated vs illegal but
backwards compatible.  Your proposal ought to point out that making
these choices legal but deprecated is going to result in a situation
where some compilers will accept the code silently, whereas other compilers
will issue warnings.  But your and Koening's proposal doesn't do
any of these analyses. Thus Koeing doesn't seem to be holding himself to
his own set of requirements when proposing a change to the language?

* This proposal is going to require changes to the standard in tens,
if not hundreds of places, yet the proposal does not call out what
nor where any of those changes are going to be.  At the very least I
would expect to see the proposed changes to explicit and implicit
type coercion sections, and function overloading rules, and a list
of changed library APIs.  Without concrete proposals for changed wording
of affected sections, I don't see what the committee thinks they are
agreeing to?

* When I put forward a modest proposal to change a few words of the
proposed standard in a couple places, my proposal was tied up in the
so-called extensions committee for three years, at which point in time
the committee basically said there wasn't enough time to consider these
few iota changes.  Whereas your and Koenig's extensions changes the proposed
standard in tens if not hundreds of [as yet unspecified] places, yet
it was pushed through the committee in a couple of months.  How do your
guys explain these discrepancies in treatment?  Did you guys' bool
extension to the language even go through the extensions committee?
How do you guys justify making these major changes late in the game
when other much more minor changes are considered 'too late'?

In article <CJ5tAB.9o7@tempel.research.att.com> ark@tempel.research.att.com (Andrew Koenig <9577-82971> 059113A) writes:
|In article <CJ4Fuo.DJt@microsoft.com> jimad@microsoft.com (Jim Adcock) writes:
|
|>The concept that bools should implicitly bidirectionally coerce
|>to/from ints does not exist in other languages.  Particularly
|>in languages with overloading and implicit constructors/
|>coercion operators.  My concern is with the extent to which
|>coercion ambiguities are being added to the language.
|
|The concept that chars should implicitly bidirectionally coerce
|to/from ints does not exist in other languages.  Particularly
|in languages with overloading and implicit constructors/
|coercion operators.
|
|The concept that floats should implicitly bidirectionally coerce
|to/from ints does not exist in other languages.  Particularly
|in languages with overloading and implicit constructors/
|coercion operators.

These other admittedly questionable bidi conversions 1) have already
existed, so they are not being ADDED to the language, the affect
of such additions being one of many issue you and Dag fail to
analyze in your proposal, and 2) they are not related to bools,
which was the original posters question.

In article <CJ5t5A.9K8@tempel.research.att.com> ark@tempel.research.att.com (Andrew Koenig <9577-82971> 059113A) writes:
>>: Because the practice is exceedingly widespread among C and C++ programmers,
>>: the proposal accommodates it temporarily as a transition aid.  The intent is
>>: to remove ++ on bool values in the next version of the standard.
>
>>I have never seen this happen in practice.
>
>Neither have I, because neither C nor C++ has gone into the second version
>of its standard.

They won't got into a second version of the standard because it is
more convenient for language developers to change the name of the
language.  Then the new committee members can claim they have no
responsibility towards the previous language, whether in removing
previously deprecated features, implementing previously proposed features,
continuing to support features in the previous language that had not
yet been deprecated, etc.  So, 'next time' the deprecated feature WON'T
be removed from C++ -- because it won't be called C++ -- but rather will
be renamed something new and suitably clever by whatever new guy or guyess is
silly enough to bend his/her pick on this problem.

The only redeaming value of this whole approach is that I can look
forward with great glee towards the day when the one-time C++ committee
members are now the old-farts pushed over on the side, whining about
backwards compatibility, the loss of efficiency and simplicity, the
erroneous assumption that previous 'intelligent engineering compromises'
were in fact in error, that the new committee members haven't even
bothered to read lest understand the previous standardization effort....

In article <SOLOMON.94Jan6094233@gjetost.cs.wisc.edu> solomon@gjetost.cs.wisc.edu (Marvin Solomon) writes:

> With regard to the exchange between Andrew Koenig and others regarding
> the question of "special treatment" for new reserved words, there's a
> substantive argument that Andrew appears to be missing, perhaps because
> it's wrapped in so much extraneous junk.  I'll try one more time to explain
> with a concrete example. Code such as this:
>  typedef int Boolean;
>  #define FALSE 0
>  #define TRUE 1
>
>  Boolean verbose;
>  ...
>  while ((c = getopt(argc,argv,"v"))!=EOF) switch (c) {
>      case 'v': verbose++; break;
> will not be affected at all.  It may be that the programmer really wants
> 'verbose' to be an integer so that he can write, e.g.,
>  if (verbose) some_debugging_output();
>  if (verbose > 1) some_really_obscure_debugging_output();

No, I'm not missing that argument.

Indeed, I even mentioned it once before -- code that uses a type name
like `Boolean' to denote some other concept is just too far out to
consider changing under this proposal.

So in this case, I would give the programmer a little credit for taste
and rewrite the code this way:

>  bool verbose;
>  ...
>  while ((c = getopt(argc,argv,"v"))!=EOF) switch (c) {
>      case 'v': verbose++; break;

and if it broke I would have learned something about the author.

> In this case, one might reasonably question the choice of the name "Boolean".

Yup.

> It's only if the programmer happened to use the identifier 'bool', that
> he has a problem with the proposed change.  He then has two choices:
>     - change the name to something else, such as "my_bool"
>     - make sure all uses really do conform to "standard" useage of the new
>       bool type.

Yes indeed.

> In this way, the situation is no different from programs that happen to use
> "try" or "catch" or "template".

...except that the second alternative is impossible for `try,' `catch,'
or `template' so there is no need to consider how to accommodate it.

> Finally, my vote:  I like the idea of a first-class Boolean type
> (especially so that I can overload 'operator bool()'), BUT I'd prefer
> it not be in the standard.

If it's not, you won't have it no matter how much you like it.

> I agree with Ron Guillemet (sp?):
> The standards people should be standardizing the *current* language, not
> new features, however worthwhile.  There could be separate "extensions
> standards" that suggest a particular form for each proposed new feature
> (meaning, for example "If you want to add a boolean type, here's how you
> should do it"), or extensions could simply be deferred
> to version II of the standard.  The way things are going now, there
> may never be a version II, since there may never be a version I :-).

I wish things were that simple.

The trouble is that if no extensions were considered at all, the
result would a C++ standard that would be both timely and useless.
Useless because everyone would ignore it and add their own proprietary
extensions, as they did with the Pascal standard.
--
    --Andrew Koenig
      ark@research.att.com

From: solomon@gjetost.cs.wisc.edu (Marvin Solomon @ CS Department, University of Wisconsin)

 > The standards people should be standardizing the *current* language, not
 > new features, however worthwhile.  There could be separate "extensions
 > standards" that suggest a particular form for each proposed new feature
 > (meaning, for example "If you want to add a boolean type, here's how you
 > should do it"), or extensions could simply be deferred
 > to version II of the standard.

Like the Pascal and Pascal 2 standards? That would leave the field wide
open for a separate ``industry standard'' - like Turbo Pascal. The extensions
issue isn't simple, and as far as I can judge every successful standards
effort for a widely used language have embraced extensions to be relevant
at the time of completion. I will not try to discuss these issues in detail
here. I have addressed them in

 Bjarne Stroustrup: Why Consider Language Extensions?
 The C++ Report. Vol 5 no 7

and
 Bjarne Stroustrup: How to Write a \*C Language Extension Proposal.
 The C++ Report. May 1992.

Dealing with extensions involves difficult tradeoffs between diverse needs
and concerns. I expect that the committee will be largely successful in that
balancing act.

 > The way things are going now, there
 > may never be a version II, since there may never be a version I :-).

Very funny, and somewhat at odds with reality.

I encourage people to be rather selective in what information they believe
about the standards effort. In particular, I would be weary of second hand
information and conjectures. (this is NOT meant as a criticism of Marvin's
posting, just as a general observation).

I note that Dag Bruck is an ISO national representative and that Andrew
Koenig is one of AT&T's representatives and the project editor. They both
have attended all meeting (unless my memory fails me) and both are under
obligation to be accurate and factual in their description of committee affairs.

 - Bjarne

In article <damian.757895503@bruce.cs.monash.edu.au> damian@cs.monash.edu.au (Damian Conway) writes:

>  1. Would you care to elaborate on the likely path of divergence?

At this point, I have only second-hand information.  However, for example,
I believe that C is planning on introducing complex numbers as built-in
types while C++ will have them as part of its standard library.

More generally, because the reconstituted C committee is just getting started,
it seems inevitable that they will still be adding things to C at a point when
the C++ committee can no longer make significant changes without abandoning
its schedule.

It is hard to see how to avoid this.
--
    --Andrew Koenig
      ark@research.att.com

In article <CJ80oA.C5v@microsoft.com> jimad@microsoft.com (Jim Adcock) writes:

> * The proposal DOES NOT do any of the competing-alternatives analysis
> that Koenig claims is required before adding any extensions to the
> language.

I do not claim, and have never claimed, that such analysis is required.

> * When I put forward a modest proposal to change a few words of the
> proposed standard in a couple places, my proposal was tied up in the
> so-called extensions committee for three years, at which point in time
> the committee basically said there wasn't enough time to consider these
> few iota changes.  Whereas your and Koenig's extensions changes the proposed
> standard in tens if not hundreds of [as yet unspecified] places, yet
> it was pushed through the committee in a couple of months.  How do your
> guys explain these discrepancies in treatment?  Did you guys' bool
> extension to the language even go through the extensions committee?
> How do you guys justify making these major changes late in the game
> when other much more minor changes are considered 'too late'?

It is easy to account for the discrepancy.

In order for a proposal to be accepted, the committee must vote to accept it.

In order for the committee to vote on anything, there must be a voting member
physically present at the meeting who is willing formally to move the proposal.

In practice, before anyone will make a formal motion that
involves an extension, the extension must first be approved
by the Extensions Working Group.

The Extensions Working Group usually does not consider extensions unless
someone is physically there to propose them.  That person does not
have to be the original author of the proposal, but unless at least one
member favors an extension strongly enough to argue for it,
there is no point in even discussing it.


You sent in a paper that contained a proposal but never attended a
meeting to actually propose it.  Nevertheless, Bjarne, the chair
of the Extensions working group, left it on the agenda for several
meetings in the hope that either you or someone else would show up
to champion the proposal.  Finally, in the London meeting, Bjarne
said that unless someone was willing to champion your proposal,
he would drop it from the agenda.  Moreover, in light of the fact
that I had written a paper raising some questions about the proposal,
he suggested that whoever did decide to champion it should be prepared
to answer those questions, as I would surely be interested in asking
them in person at the meeting at which it was proposed.

On person did volunteer and said he would (a) write a paper that answered
my questions and (b) would show up at the next meeting.  The proposal
was therefore tabled until then.

For the next meeting, he did indeed submit a paper.  That paper was
simply a paraphrase of your original proposal.  It provided no new information
and made no attempt to answer any of the questions I had raised.

Moreover, he did not show up at the meeting.

On that basis, Bjarne asked if anyone else was willing to champion
your proposal.  No one was, so he put it to a vote and it was voted down.


In the case of Dag's and my proposal, Dag went to the Extensions WG meeting,
as he has done regularly since the committee started.  He made the proposal,
there was a half hour of discussion in which several modifications were
proposed and accepted, and the proposal was then voted in.  It was then
moved before the full committee, who also voted to accept it.


If you came to meetings as regularly as Dag does, perhaps your story
might have been different too.  If you had convinced the Microsoft
representative to champion your cause, you might have succeeded that
way too.  But in general, the committee does not act on proposals submitted
by non-members unless a member is willing to take responsibility for it.
--
    --Andrew Koenig
      ark@research.att.com

In article <CJ817p.D02@microsoft.com> jimad@microsoft.com (Jim Adcock) writes:

> These other admittedly questionable bidi conversions 1) have already
> existed, so they are not being ADDED to the language, the affect
> of such additions being one of many issue you and Dag fail to
> analyze in your proposal, and 2) they are not related to bools,
> which was the original posters question.

Oh no...they're fundamental.  A large part of the confidence in the bool
proposal rests on the notion that it just adds yet one more integral type,
like wchar_t.  That gives confidence that, for example, the mere existence
of type bool doesn't change overloading behavior in programs that don't
use it.
--
    --Andrew Koenig
      ark@research.att.com

In article <CJ826B.E80@microsoft.com> jimad@microsoft.com (Jim Adcock) writes:

> >Neither have I, because neither C nor C++ has gone into the second version
> >of its standard.

> They won't got into a second version of the standard because it is
> more convenient for language developers to change the name of the
> language.

Go tell that to the C standards committee, which is even now beginning work
on the second version of the C standard.

> The only redeaming value of this whole approach is that I can look
> forward with great glee towards the day when the one-time C++ committee
> members are now the old-farts pushed over on the side, whining about
> backwards compatibility, the loss of efficiency and simplicity, the
> erroneous assumption that previous 'intelligent engineering compromises'
> were in fact in error, that the new committee members haven't even
> bothered to read lest understand the previous standardization effort....

Thank you for stating your opinion of C++ for the record.
--
    --Andrew Koenig
      ark@research.att.com

ark@tempel.research.att.com (Andrew Koenig) writes:

|"In article <damian.757895503@bruce.cs.monash.edu.au> damian@cs.monash.edu.au (Damian Conway) writes:

|">  1. Would you care to elaborate on the likely path of divergence?

|"At this point, I have only second-hand information.  However, for example,
|"I believe that C is planning on introducing complex numbers as built-in
|"types while C++ will have them as part of its standard library.

|"More generally, because the reconstituted C committee is just getting started,
|"it seems inevitable that they will still be adding things to C at a point when
|"the C++ committee can no longer make significant changes without abandoning
|"its schedule.

Will this mean that the C++ standard will contain clauses to the effect that
certain things will be considered `floating' until the C standard committee is
finished ? In what ways will proposals for extensions of the C standard
influence the C++ standard committee ?
--
Ronald van Loon       | E-mail: rvloon@motif.hacktic.nl <-- note NEW address!
Maintainer of Motif++ | S-mail: St. Janskerkhof 18, 3811 HW  AMERSFOORT
                      |         The Netherlands.
Job offers welcome.   | Phone : +31 33 758 293. (FAX: available on request)
 -----------------------------------------------------------------------------
| My current address (rvloon@cv.ruu.nl) will no longer be valid after         |
| January 1st, 1994. Please send new mail to rvloon@motif.hacktic.nl instead. |
| Note that this is a UUCP connection, which means that answering messages    |
| may take longer than before.                                                |
 -----------------------------------------------------------------------------

>From: solomon@gjetost.cs.wisc.edu (Marvin Solomon @ CS Department, University of Wisconsin)
> > The standards people should be standardizing the *current* language, not
> > new features, however worthwhile...

In article <CJ881B.yq@tempel.research.att.com> ark@tempel.research.att.com (Andrew Koenig) writes:
>The trouble is that if no extensions were considered at all, the
>result would a C++ standard that would be both timely and useless.
>Useless because everyone would ignore it and add their own proprietary
>extensions, as they did with the Pascal standard.

In article <27482@alice.att.com> bs@alice.att.com (Bjarne Stroustrup) writes:
>Like the Pascal and Pascal 2 standards? That would leave the field wide
>open for a separate ``industry standard'' - like Turbo Pascal.

This analogy does not convince someone who actually used Pascal prior to
the ANSI/ISO standards and prior to Turbo Pascal.

The failure of the ANSI Pascal committee was not just its refusal to invent
extensions, but its refusal to adopt any of the extensions that were already
widespread in commercial compilers (Turbo Pascal was far from the first). The
ISO committee was even later to market than ANSI.

The ANSI standard language was so crippled that one could hardly write a
competitive commercial application without violating it:

 You could not implement a variable-length string or array, except by
   either violating bounds checking, or by allocating enough storage
   for every string to accomodate the largest possible string. When
   you wanted to assign a constant initial value to a variable string,
   you had to pad the constant with enough blanks to match the length.
   In practice, this meant people would write umpteen different copies
   of the same code, each copy targeted toward a different size of
   string or array.

 There were no pointers to static or local objects, only to heap
   objects.

 Case statements had no default clause. Either you enumerated every
   single possible value of the index variable, or you used "if"
   statements.

 There was no generic pointer type, and no generic type conversion
   mechanism (except by case-variant trickery that broke the rules).

 Files did not permit random access or appending.

 Separate compilation was not allowed.

Does the absence of a "boolean" type cripple C++ to this extent?  C++ is
avowedly user-extensible, so what does the "boolean" proposal accomplish which
the user cannot accomplish by writing a class? If the proposal were abandoned,
would vendors add "boolean" as an extension to the compiler rather than
providing it in a class library?

Those are the questions I would ask at the 11th hour of the standardization
process.
--
Steven Correll == PO Box 66625, Scotts Valley, CA 95067 == sjc@netcom.com

In <comp.std.c++> rvloon@motif.hacktic.nl (Ronald van Loon) writes:
>
>Will this mean that the C++ standard will contain clauses to the effect that
>certain things will be considered `floating' until the C standard committee is
>finished ? In what ways will proposals for extensions of the C standard
>influence the C++ standard committee ?

It is very hard to answer this question now, because there have been
few "real" issues in this area to discuss so far.

    -- Dag

In article <2gkv2p$l7@motif.hacktic.nl> rvloon@motif.hacktic.nl (Ronald van Loon) writes:

> |"More generally, because the reconstituted C committee is just getting started,
> |"it seems inevitable that they will still be adding things to C at a point when
> |"the C++ committee can no longer make significant changes without abandoning
> |"its schedule.

> Will this mean that the C++ standard will contain clauses to the effect that
> certain things will be considered `floating' until the C standard committee is
> finished ? In what ways will proposals for extensions of the C standard
> influence the C++ standard committee ?

That's the whole point -- it can't.  At some point, the language defined
by the C++ standard must be frozen, and that point will almost certainly
be well before the C committee has finished its work.
--
    --Andrew Koenig
      ark@research.att.com

I've been waiting for someone to post the bool proposal, as an earlier
poster requested. But no one has. So-o-o ...

Why can't the integral types be made more consistent, giving the
programmer control over usage and (to some extent) size? Why not
introduce keyword 'bool' with the same status as 'signed'? Why not
allow:

bool b; //int is implicit
bool char b1;
bool short b2;
bool int b3;
bool long b4; //Well, maybe I want to add all the true flags to a long int sum!
char enum day{SUN, MON, TUE, WED, THU, FRI, SAT};
bool char enum switch_position{OFF, ON};
short unsigned enum bit{BIT15 = 0x8000, BIT14 = 0x4000, .........

Chris Perrott

In article <2g0vqe$ean@nic.lth.se> dag@control.lth.se (Dag Bruck) writes:
>In <comp.std.c++> rfg@netcom.com (Ronald F. Guilmette) writes:
>>
>>Several people (including myself) have here questioned both the need for,
>>and the details of this whole `bool' idea.  I think that indicates something
>>in and of itself.
>
>Ron, you were present at the standards meeting in San Jose where the
>proposal was discussed and accepted.

Due to other pressing business, I was only there for a couple of afternoons...
Not the entire five days.

>Why didn't you speak up at the meeting, instead of hashing it all over
>on the net after it was accepted?

Simple.  I attended the meeting only as an interested member of the public
at large.  Having not paid any dues for X3J16 membership during 1993, I
felt that I had no voice in that assembly.  (Had I instead been a paid-up
member, I'm quite sure I would have decried the entire idea.)

>Why didn't you talk to me and raise your concerns when I was there?

Quite frankly, on the afternoons I attended, the bool proposal was not even
mentioned... and I didn't even know that it was comming up for a vote.  Had
I known, I might indeed have privately expressed some strenuous opposition.

--

-- Ronald F. Guilmette, Sunnyvale, California -------------------------------
------ domain address: rfg@netcom.com ---------------------------------------
------ uucp address: ...!uunet!netcom.com!rfg -------------------------------

In article <2512@swuts.sbc.com> sg3235@sw1sta.sbc.com (Stephen Gevers) writes:
>
>I am going to open a can of worms here: When I first used C++, I thought that
>C++ would differentiate between two typedefs.  I was disappointed when I found
>that it wouldn't work.  It would be nice if there existed a keyword that would
>actually become a new type (sort of like typedef).  This way, overloading
>could be done on things like pid_t, size_t, etc.

Indeed.  A nice idea.  (As it happens, this feature is available in Ada.)

>This would also solve the bool overloading problem...

Maybe.

--

-- Ronald F. Guilmette, Sunnyvale, California -------------------------------
------ domain address: rfg@netcom.com ---------------------------------------
------ uucp address: ...!uunet!netcom.com!rfg -------------------------------

In article <CJ881B.yq@tempel.research.att.com> ark@tempel.research.att.com (Andrew Koenig) writes:
>In article <SOLOMON.94Jan6094233@gjetost.cs.wisc.edu> solomon@gjetost.cs.wisc.edu (Marvin Solomon) writes:
>> Finally, my vote:  I like the idea of a first-class Boolean type
>> (especially so that I can overload 'operator bool()'), BUT I'd prefer
>> it not be in the standard.
>
>If it's not, you won't have it no matter how much you like it.

This is (I believe) the central falacy which lies beneath a good number of
X3J16's inumerable untested extensions.

Many people in the committee seem often to be oblivious to the fact that
almost every compiler for every "standardized" language provides some
extensions (of the vendor's choosing).

If `bool' (or any other "late" extension) is really that great, then why not
just wait for Borland, Microsoft, USL, IBM, and everyone else to add it
to their compilers on their own?  Why force it down everyone's throat by
making it a required part of the base standard?

As far as I have been able to make out, there is only one plausible answer
to this question.

It seems that in all facets of modern life (including language standardization)
there is always an abundance of folks (e.g. the Moral Majority) who are damn
certain that they know just what's best for everyone else, and who are more
than ready to enact laws, rules, regulations, etc., to insure that everyone
else lives up to their own high ideals.

Needless to say, I don't believe that this sort of moralizing has any place
in what should be a simple effort to standardize an existing language.

It is certainly that case that many Good Things could be "tacked on" to C++
as it now stands, but there are well more than enough features in there now
to make a good base standard.  Additional features should be left to in-
dividual implementors to provide when (and if) their respective customer
bases actually express some desire (i.e. *any* desire) for the additional
features.

--

-- Ronald F. Guilmette, Sunnyvale, California -------------------------------
------ domain address: rfg@netcom.com ---------------------------------------
------ uucp address: ...!uunet!netcom.com!rfg -------------------------------

In article <sjcCJABDv.A7B@netcom.com> sjc@netcom.com (Steven Correll) writes:

> If the proposal were abandoned,
> would vendors add "boolean" as an extension to the compiler rather than
> providing it in a class library?
>
> Those are the questions I would ask at the 11th hour of the standardization
> process.

The answer, pretty clearly, is that vendors would (i.e., actually do)
add the boolean type as part of a class library.  That, of course, is
the main motivation for adding it to the C++ standard: multiple
vendors are all implementing boolean types in incompatible ways.  This
is exactly the sort of situation that standardization is intended to
rectify.

Of course, saying that a boolean type ought to be part of the Standard
says nothing about whether it ought to be part of the language, or
part of the standard class library.  In this particular case, I'm
inclined to think that it doesn't make much difference.
--
Matthew Austern                       Never express yourself more clearly
matt@physics.berkeley.edu             than you think.    ---N. Bohr

In article <2512@swuts.sbc.com> sg3235@sw1sta.sbc.com (Stephen Gevers) writes:
>>
>>I am going to open a can of worms here: When I first used C++, I thought that
>>C++ would differentiate between two typedefs.
>>This would also solve the bool overloading problem...

Not on its own.  I think a boolean datatype is pretty useless if an
expression such as

 x > 3

does not return boolean.  In C and in present C++ it returns int.

This implies that regardless of the definition of boolean (typedef,
class, new integral type, enum), you must also change the language so
"x > 3" returns boolean instead of int.  A pure library extension will
not do that.

     -- Dag

In article <rfgCJCsGy.IpD@netcom.com>, rfg@netcom.com (Ronald F. Guilmette) writes:
|> In article <CJ881B.yq@tempel.research.att.com> ark@tempel.research.att.com (Andrew Koenig) writes:
|> >In article <SOLOMON.94Jan6094233@gjetost.cs.wisc.edu> solomon@gjetost.cs.wisc.edu (Marvin Solomon) writes:
|> >> Finally, my vote:  I like the idea of a first-class Boolean type
|> >> (especially so that I can overload 'operator bool()'), BUT I'd prefer
|> >> it not be in the standard.
|> >
|> >If it's not, you won't have it no matter how much you like it.
|>
|> This is (I believe) the central falacy which lies beneath a good number of
|> X3J16's inumerable untested extensions.
|>
|> Many people in the committee seem often to be oblivious to the fact that
|> almost every compiler for every "standardized" language provides some
|> extensions (of the vendor's choosing).
|>
|> If `bool' (or any other "late" extension) is really that great, then why not
|> just wait for Borland, Microsoft, USL, IBM, and everyone else to add it
|> to their compilers on their own?  Why force it down everyone's throat by
|> making it a required part of the base standard?
|>
|> As far as I have been able to make out, there is only one plausible answer
|> to this question.
|>
...stuff where Ron goes non-linear deleted.
|>
|> --
|>
|> -- Ronald F. Guilmette, Sunnyvale, California -------------------------------
|> ------ domain address: rfg@netcom.com ---------------------------------------
|> ------ uucp address: ...!uunet!netcom.com!rfg -------------------------------

Ron:

  For the most part all the compiler vendors are on the committee.
They seek to provide a product that is *both* standard and that
contains the functionality requested by customers.  These committee
members are balancing the need for rapid standardization against
the reality that the standard will box them in for a few years.
The committee is ``everyone'': the vendors are colluding to shorten
the time it would take to create a de-facto standards via
implementation dependent extensions.  Yes, its a conspiracy, but one
that we need.

Its not a perfect process; its not a perfect world.  Its worth living
with the compromises. Someday perhaps we can devise an electronic
means of debate more focused than comp.std.c++ allows, so that all
sides of "new bool type" can be heard and compared, while also
allowing all sides of "untested extensions" to be considered and
debated...in a separate arena.

--
John.

John J. Barton        jjb@watson.ibm.com            (914)784-6645
H1-C13 IBM Watson Research Center P.O. Box 704 Hawthorne NY 10598

In article <rfgCJCsGy.IpD@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:

> If `bool' (or any other "late" extension) is really that great, then why not
> just wait for Borland, Microsoft, USL, IBM, and everyone else to add it
> to their compilers on their own?  Why force it down everyone's throat by
> making it a required part of the base standard?

Well, in fact the committee did wait, and everyone did add it to their
compilers.  It's just that vendors put it in libraries, instead of in
the base compilers.

My own opinion is that bool isn't really necessary: I'm happy enough
using ints to represnt truth and falsehood.  Most compiler and library
vendors, though, seem to disagree with me.  The current situation is
exactly the sort where standardization is called for: everyone is
implementing a particular feature, but they're all implementing it
slightly differently, thus creating an impediment to portability.

One might quibble about whether the new bool type should be a base
type, or a class defined in the standard class library, but that's
really not much more than a quibble.  Nowadays, the line between the
language and the standard library is a bit fuzzy.

--
Matthew Austern                       Never express yourself more clearly
matt@physics.berkeley.edu             than you think.    ---N. Bohr

Oops, I seem to have struct a nerve.  Sorry Bjarne, I'm aware of the
valiant effort the committee is making to adhere to its schedule, and, from
having dabbled a bit in standards making (in a different area) I am well
aware of the difficulties involved.  I apologize for the cheap shot.

Reasonable people can still disagree, however, on the correct place to draw
the line in the sand when closing the gate before the bus leaves the
station (sorry for the mixed metaphore).  I guess templates were probably
worth adding and one can make a good case for exceptions--although one
might make a reasonable argument against both of them.  Even MI is somewhat
controversial.  It's a very slippery slope though, as Bjarne points out so
clearly in the articles he cites.  I tend to agree with Steven Correll that
the Pascal standard failed not simply because it refused to include
extensions but because it refused to recognize extensions already in
widespread use.  It is also possible to cite examples from the other
extreme. The networking area is filled with examples of standards
that sank under the weight of "good ideas" that were too far ahead of their
time.  A good example is the contrast between CMIP (Common Management
Information Protocol) which loaded with useful--but complex--features and
SNMP (Simple Network Management Protocol), which is (IHMO) excessively
over-simplified.  Nevertheless SNMP has completely taken over the market,
and they are now working on version 2, which puts back some of the more
important missing features.
--
Marvin Solomon                  Professor and Chair
Computer Sciences Department    University of Wisconsin
1210 W. Dayton St.              Madison WI, USA
(608) 262-1204                  solomon@cs.wisc.edu

In article <CJDLKF.2Kqn@hawnews.watson.ibm.com> jjb@watson.ibm.com (John Barton) writes:

> The committee is ``everyone'': the vendors are colluding to shorten
> the time it would take to create a de-facto standards via
> implementation dependent extensions.  Yes, its a conspiracy, but one
> that we need.

It is also a conspiracy that, if it took place outside the standards process,
would potentially be subject to legal sanction as restraint of trade.
Official standards bodies apparently have some degree of exemption from
antitrust restrictions, presumably by virtue of their open membership.
--
    --Andrew Koenig
      ark@research.att.com

ark@tempel.research.att.com (Andrew Koenig) writes:

>In article <damian.757895503@bruce.cs.monash.edu.au> damian@cs.monash.edu.au (Damian Conway) writes:

>>  1. Would you care to elaborate on the likely path of divergence?

>At this point, I have only second-hand information.  However, for example,
>I believe that C is planning on introducing complex numbers as built-in
>types while C++ will have them as part of its standard library.

What would happen if the bool type was part of a standard library
instead of a built-in type? It would still be possible to do the
desired overloading, and it would be possible to decide not to use it
for those who don't like it.

Are there other pros and cons?

 Johan Garpendahl

joga@ppls1c217.ppvlu (Johan Garpendahl) writes:

>What would happen if the bool type was part of a standard library
>instead of a built-in type? It would still be possible to do the
>desired overloading, and it would be possible to decide not to use it
>for those who don't like it.

No, as has been described on this forum several times already,
it wouldn't be possible to do the desired overloading if bool
bool was not a built-in type.

Consider for example the following program:

 #include <iostream.h>
 int main() {
  int x = 1, y = 2;
  cout << (x == y) << endl;
  return 0;
 }

The "desired overloading" is that this should call

 operator<<(ostream&, bool);

which should output a string such as "false" or "true", not a number.
This is not possible unless bool is a builtin type.

--
Fergus Henderson        |   "People who brook no compromise in programming
                        |   languages should program in lambda calculus or
fjh@munta.cs.mu.OZ.AU   |   machine language, depending." --Andrew Koenig.

>>>>> Regarding Re: new bool type; cperrott@retina.mpce.mq.edu.au (Chris Perrott) adds:

> Why can't the integral types be made more consistent, giving the
> programmer control over usage and (to some extent) size? Why not
> introduce keyword 'bool' with the same status as 'signed'? Why not
> allow:

> bool b; //int is implicit
> bool char b1;
> bool short b2;
> bool int b3;
> bool long b4; //Well, maybe I want to add all the true flags to a long int sum!
> char enum day{SUN, MON, TUE, WED, THU, FRI, SAT};
> bool char enum switch_position{OFF, ON};
> short unsigned enum bit{BIT15 = 0x8000, BIT14 = 0x4000, .........

Good taste, apart from other things.  bool is a new, quite specific,
type.  It's designed to represent true and false.  I don't see what
"bool int", "bool char", etc., are supposed to mean.  As far as I can
see, they are meaningless.  As meaningless as char int.

> Chris Perrott
--
Bruce                    Institute of Advanced Scientific Computation
bruce@liverpool.ac.uk    University of Liverpool

In article <1993Dec15.092048.13770@us-es.sel.de> kocher@us-es.sel.de (Hartmut Kocher) writes:
>In article <27374@alice.att.com>, ark@alice.att.com (Andrew Koenig) writes:
>>
>> That's simply not true.  There are plenty of programs that do things like:
>>
>>  typedef int bool;
>>
>>  bool aflag, bflag, cflag, dflag;
>>
>>  // ...
>>
>>   switch (optchar) {
>>   case 'a':
>>    ++aflag;
>>    break;
>...
>
>>   casd 'e':
>>    ++dflag;
>>    break;
>>   // ...
>>   }
>>
>> The point is to be able to remove the `typedef int bool;' declaration
>> and have this program still work.
>> --
>>     --Andrew Koenig
>>       ark@research.att.com
>
>IMHO, programs like this deserve to be broken! If someone uses booleans
>he should use them right.

I agree, and I think this point illustrates a lot of what has gone wrong
with the ``design by committee'' that's been going on the C++ standardization
committee.  Those folks have gone to great lengths to preserve a huge number
of ancient language warts, ostensibly for the sake of maintaining old legacy
code (a consideration which is, after all completely irrelevant to this
discussion on the bool type, but I digress).  I haven't noticed the
committee ever questioning the wisdom of maintain code which was brain-
damaged to begin with.

--

-- Ronald F. Guilmette, Sunnyvale, California -------------------------------
------ domain address: rfg@netcom.com ---------------------------------------
------ uucp address: ...!uunet!netcom.com!rfg -------------------------------

In article <2eq1tk$as3@crchh7ab.bnr.ca> davisonj@ecn.purdue.edu (John Davison) writes:
>        In article <27387@alice.att.com>, ark@alice.UUCP (Andrew Koenig) wrote:
>>In article <1993Dec15.092048.13770@us-es.sel.de> kocher@us-es.sel.de (Hartmut
>Kocher) writes:
>>
>>> IMHO, programs like this deserve to be broken!
>>
>>It doesn't metter --
>>the standards committee does not have the right to break them.
>
>        But they have the right to break "typedef int bool;"...?

Quite so.

I do not think this point can be over-emphasized.

To say that the C++ standardization committee has never made any rules
which break existing C or C++ code is almost like saying that the pope
has never said mass!

In light of that, ark's contention seems more than a little bit... well...
ridiculous.

(Oh, and by the way, I think it's rather painfully evident that both the
need for, and the details of this whole bool idea have been shown here to
be basically indefensible.  I'm sure most regular readers of this newsgroup
have been able to figure that out by now, just by counting the number of
messages which the `bool' proponents have felt it necessary to post here
in their attempts to defend both the general concept and the specific
details.)

--

-- Ronald F. Guilmette, Sunnyvale, California -------------------------------
------ domain address: rfg@netcom.com ---------------------------------------
------ uucp address: ...!uunet!netcom.com!rfg -------------------------------

In article <2estk7$242@nic.lth.se> dag@control.lth.se (Dag Bruck) writes:
>In <comp.std.c++> rfg@netcom.com (Ronald F. Guilmette) writes:
>>
>>If it was indeed the intent of the C++ standardization committee to have
>>this new (and different) type act very much like int, then one might well
>>ask why int was not considered good enough in the first place.
>
>Because we wanted overloading on bool.  A great number of people
>distinguish between booleans and integers, and want to express that in
>their C++ code.
>
>>If, on the other hand, the committee really *did* want a new and distinct
>>type (I assume as a way of enhancing ``type-safety'') then one must wonder
>>why this goal was not actually persued to its logical conclusion.
>
>Because we want to make the transition, i.e., porting existing code to
>the new rules, as easy as possible.
>
>(As a side note: my experience is that persuing something to its
>logical conclusion does not work well when there are conflicting
>interests, which the net discussion has shown.)

There is an old saying that a camel is a horse which was designed by committee.

It seems particularly apropos in this context.

--

-- Ronald F. Guilmette, Sunnyvale, California -------------------------------
------ domain address: rfg@netcom.com ---------------------------------------
------ uucp address: ...!uunet!netcom.com!rfg -------------------------------

In <comp.std.c++> rfg@netcom.com (Ronald F. Guilmette) writes:
>In article <...> kocher@us-es.sel.de (Hartmut Kocher) writes:
>>IMHO, programs like this deserve to be broken! If someone uses booleans
>>he should use them right.
>
>I agree, and I think this point illustrates a lot of what has gone wrong
>with the ``design by committee'' that's been going on the C++ standardization
>committee.

The problem is that not everybody will agree on what (or who) is brain
damaged.  Hartmut Kocher doesn't have the power to tell me what is
"right."  The C++ standardization committee has, so it must be careful
in using it's power.

Neither Ron Guilmette nor I have achieved everything we want wrt C++,
but I have at least reason to be satisfied with my work in the committee.

>....  I haven't noticed the
>committee ever questioning the wisdom of maintain code which was brain-
>damaged to begin with.

Well, I have on many occasions.  I do not understand how you can have
missed it.

    -- Dag

In <comp.std.c++> rfg@netcom.com (Ronald F. Guilmette) writes:
>
>(Oh, and by the way, I think it's rather painfully evident that both the
>need for, and the details of this whole bool idea have been shown here to
>be basically indefensible.  I'm sure most regular readers of this newsgroup
>have been able to figure that out by now, just by counting the number of
>messages which the `bool' proponents have felt it necessary to post here
>in their attempts to defend both the general concept and the specific
>details.)

I have spent considerable time explaining the proposal and answering
questions on the net.  I find Ron G. both impolite and unserious when
he uses the number of times we have answered questions as a sign of
bad work by Andrew Koenig and myself.

Instead I think it is a matter of good will and politeness to take the
time to explain your proposal to a large number of people who are
interested in C++.  However, I'm will not be suprised if Ron Guilmette
finds an argument based on the concepts of good will and politeness as
being "rediculuous."

However, it is also possible to interpret Ron's message as a plea to
simply ignore the silliest and most brain-damaged postings on the net,
and I appoligize for not having done so.

      -- Dag Bruck

Simon Tooke (simon@sco.COM) wrote:
: In <CHzA9s.Crz@biles.com> daniels@biles.com (Brad Daniels) writes:

: >In article <KANZE.93Dec9193850@slsvhdt.us-es.sel.de>,
: >James Kanze <kanze@us-es.sel.de> wrote:
: >...
: >>I think that the only reason for supporting x++ is to avoid breaking
: >>existing programs.  It is not meant that this be the normal way of
: >>setting a bool to true.
: >>
: >>x-- was not supported because any possible interpretation would result
: >>in a silent change in some programs.  For the rare programs which use
: >>this idiom, it was felt that it was better to let the compiler give an
: >>error rather than perhaps doing the wrong thing.
: >>
: >>Please understand that the consistency argument has no weight here.
: >>From a purely logical point of view, neither operator would be
: >>supported.  Pragmatics means trying to avoid breaking existing
: >>programs.  Defining x++ to mean x=true helps; there is no plausible
: >>definition for x-- which would help.

: >I suspect you are right that x++ is supported to avoid breaking existing
: >programs, but the logic here eludes me completely.  *No* existing program
: >uses a variable of type bool, and therefore, *no* exisiting program uses
: >operator++ on a bool variable.  There is absolutely no need to support
: >operator++ on bools, at least from the standpoint of backward compatibility.

Thank you for stating what I've been wanting to say from the moment I began
reading about the new boolean type.  What I'd like to add is several leading
questions.

 1) Why does this proposal attempt to accomodate keyword conflicts
 when no previous proposal has set such a precedent?  Anyone who had
 a variable/type/class called "template", "try", etc ... was/is
 out-of-luck with the recent additions to C++.

 2) Why is the C++ committee supporting backward compatibility to
 practices that are at least confusing, and at most potentially buggy?
 I refer to the use of ++ on boolean objects.  In the former, its
 obvious from this thread that no one can agree on how it should work,
 and in the latter, the overflow case pointed out earlier gives me
 chills (a bug that could take years to appear).  Such practices should
 be made impossible to perform in a language, not accomodated.

 3) Why is the C++ committee so worried about breaking C++ code while
 it is still in the early stages of standardization?  While I applaud
 the effort to avoid conflicts, I tend to draw the line when it is
 going to alter the final language standard in non-intuitive ways.

 4) Isn't the current state of C++ difficult enough for new-comers to
 grasp?  C++ already has a number of "remember that this works like this
 because that".

Is it worth adding more caveats to the language just so a few people don't
have to do a search and replace on the bool keyword?  BTW if this is such a
major problem, the compiler could handle this with a simple command line
switch.

-Stephen

In article <2fum9a$bgu@nic.lth.se> dag@control.lth.se (Dag Bruck) writes:
>In <comp.std.c++> rfg@netcom.com (Ronald F. Guilmette) writes:
>>
>>(Oh, and by the way, I think it's rather painfully evident that both the
>>need for, and the details of this whole bool idea have been shown here to
>>be basically indefensible.  I'm sure most regular readers of this newsgroup
>>have been able to figure that out by now, just by counting the number of
>>messages which the `bool' proponents have felt it necessary to post here
>>in their attempts to defend both the general concept and the specific
>>details.)
>
>I have spent considerable time explaining the proposal and answering
>questions on the net.  I find Ron G. both impolite and unserious when
>he uses the number of times we have answered questions as a sign of
>bad work by Andrew Koenig and myself.

I freely admit to being impolite, but I am dead serious.

Several people (including myself) have here questioned both the need for,
and the details of this whole `bool' idea.  I think that indicates something
in and of itself.  Also, you and Andrew have posted many messages in defense
of this new bool "feature".  Someone once told me that the more vigorously
someone defends an idea, the less defensible it actually is.  I can't help
feeling that that is true in this case.

We didn't really *NEED* a new bool type.  Int was perhaps less than perfect,
but it was ok.  What the C++ community *does* need however is a standard,
and the committee's time would have been better spend on resolving the
remaining HUNDREDS of open issues pending before the committee, instead
of frittering away yet more time on yet more unnecessary (and untested)
"features".

(Now before someone says that this `bool' thing *was* tested... because one
person implemented it, and then used it for a day or two... let me just say
that *my* definition of testing is having a whole community of people using
a feature, and finding its flaws, for *more* that just a week or two.)

--

-- Ronald F. Guilmette, Sunnyvale, California -------------------------------
------ domain address: rfg@netcom.com ---------------------------------------
------ uucp address: ...!uunet!netcom.com!rfg -------------------------------

In <comp.std.c++> sfc@datascope.com (Steve F. Cipolli (P/M)) writes:
>
> 1) Why does this proposal attempt to accomodate keyword conflicts
> when no previous proposal has set such a precedent?

There is precedent.  Many libraries define a boolean type, which
causes considerable problems when libraries are mixed.  One of goals
of the proposal is to get rid of this mess by agreeing on one name for
the Boolean type: "bool."

> 2) Why is the C++ committee supporting backward compatibility to
> practices that are at least confusing, and at most potentially buggy?

Because such code is common.

> I refer to the use of ++ on boolean objects.

Note that use of ++ on bool is deprecated from the start, which for
example is a strong encouragement to issue a warning at compilation.

> 3) Why is the C++ committee so worried about breaking C++ code while
> it is still in the early stages of standardization?  While I applaud
> the effort to avoid conflicts, I tend to draw the line when it is
> going to alter the final language standard in non-intuitive ways.

There exists much C++ code, even though there is no standard yet.  We
often prefer to make the transition easier by deprecating a feature
instead of banning it, leaving it to the next revision of the C++
standard to remove such "warts" on the language.  Operator ++ on bool
is such a case.


     -- Dag

In <comp.std.c++> rfg@netcom.com (Ronald F. Guilmette) writes:
>
>Several people (including myself) have here questioned both the need for,
>and the details of this whole `bool' idea.  I think that indicates something
>in and of itself.

Ron, you were present at the standards meeting in San Jose where the
proposal was discussed and accepted.

Why didn't you speak up at the meeting, instead of hashing it all over
on the net after it was accepted?

Why didn't you talk to me and raise your concerns when I was there?

As you said yourself: "I think that indicates something in and of
itself."  I think your attitude is unserious.


     -- Dag

In article <1993Dec30.162634.1493@datascope.com> sfc@datascope.com (Steve F. Cipolli (P/M)) writes:

> 1) Why does this proposal attempt to accomodate keyword conflicts
> when no previous proposal has set such a precedent?  Anyone who had
> a variable/type/class called "template", "try", etc ... was/is
> out-of-luck with the recent additions to C++.

It doesn't.  It adds three new reserved words: bool, true, and false.
If you try to use those words for any other concepts, you're out of luck.

> 2) Why is the C++ committee supporting backward compatibility to
> practices that are at least confusing, and at most potentially buggy?
> I refer to the use of ++ on boolean objects.  In the former, its
> obvious from this thread that no one can agree on how it should work,
> and in the latter, the overflow case pointed out earlier gives me
> chills (a bug that could take years to appear).  Such practices should
> be made impossible to perform in a language, not accomodated.

Because the practice is exceedingly widespread among C and C++ programmers,
the proposal accommodates it temporarily as a transition aid.  The intend is
to remove ++ on bool values in the next version of the standard.

> 3) Why is the C++ committee so worried about breaking C++ code while
> it is still in the early stages of standardization?  While I applaud
> the effort to avoid conflicts, I tend to draw the line when it is
> going to alter the final language standard in non-intuitive ways.

Because if the standard breaks too much existing code, vendors will
simply ignore it.

> 4) Isn't the current state of C++ difficult enough for new-comers to
> grasp?  C++ already has a number of "remember that this works like this
> because that".

I don't think C++ is any more difficult to grasp than any other commonly
used programming languages, provided it is well taught.  It is probably
somewhat easier to teach poorly than other languages because it doesn't
come with built-in clues as to how to use it.

>Is it worth adding more caveats to the language just so a few people don't
>have to do a search and replace on the bool keyword?  BTW if this is such a
>major problem, the compiler could handle this with a simple command line
>switch.

Not if the standard doesn't allow it and the compiler vendor wishes to
conform to the standard.  That's exactly the point.
--
    --Andrew Koenig
      ark@research.att.com

In article <rfgCIsF44.D7D@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:

>  There is an old saying that a camel is a horse which was designed
>  by committee.
>  It seems particularly apropos in this context.

Are you suggesting that camels are bad?  For those of us who are from
that part of the world, this is a very sensitive issue :-)

I propose that usefulness of the new bool type may be estimated by
looking at other languages which provide it.  Boolean type is not a
new concept, but to C/C++.  There should be empirical evidence showing
its effect on key attributes of a program (portability,
maintainability, readability, etc.)

In a previous posting you suggested that language is becoming
experimental (``designed in a lab'').  Could someone name a
concept in the language (C++) that does not exist in another
(predecessor) language?

>  --
>  -- Ronald F. Guilmette, Sunnyvale, California -------------------------------
>  ------ domain address: rfg@netcom.com ---------------------------------------
>  ------ uucp address: ...!uunet!netcom.com!rfg -------------------------------

Sincerely
Skip
--
    ********************************************************************
    *  Fariborz ``Skip'' Tavakkolian Claircom Communications Group  *
    *  fst@claircom.com   700 Fifth Ave, Suite 2100      *
    *  (206)389-7150   Seattle, WA.  98104            *
    ********************************************************************

fst@nimo.claircom.com (Fariborz Skip Tavakkolian) writes:

>In article <rfgCIsF44.D7D@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:

>>  There is an old saying that a camel is a horse which was designed
>>  by committee.
>>  It seems particularly apropos in this context.

>Are you suggesting that camels are bad?  For those of us who are from
>that part of the world, this is a very sensitive issue :-)

>I propose that usefulness of the new bool type may be estimated by
>looking at other languages which provide it.  Boolean type is not a
>new concept, but to C/C++.  There should be empirical evidence showing
>its effect on key attributes of a program (portability,
>maintainability, readability, etc.)

As the proposal now stands, in the form that it uses, bool would be
almost not distinguishable from
typedef int bool;
#define true 1
#define false 0
in case you were using C, so C never needed a saparate bool, although
many people were muddling the concepts of boolean and integral types
(like x++), and this is (in my opinion) bad style not to be encouraged.

However, in C++, there is one additional reason for wanting bool:
So that
cout << (i>3)
might deliver something like
true
    or
false
instead of 0 or 1. In short, one might to want to overload.



The current proposal wants to obtain this, while maintaining immediate
workability of existing programs, up to a certain empirical measure
(determined by how often seen) of brain-damagedness.

However, it seems that when replacing typedef int bool; by nothing,
it should not appear to be too complicated to replace all instances
of x++, or of several other bad practices by the appropriate
counterparts, when being noted by the compiler.


Such changes would appear to be rather trivial, so maybe the point
of brain damage support might be debatable, since we all in the long
run would like to have a language standard not using too many
square meters of paper and cells of brain in order to remember.
--
 David Kastrup        dak@pool.informatik.rwth-aachen.de
 Tel: +49-241-72419 Fax: +49-241-79502
 Goethestr. 20, D-52064 Aachen

My name was in the original, so I thought I'd have another go at this.  I
am neither Dag nor Andy, and do not claim to represent their viewpoint.
I do, however, support this proposal (but, like everything else I saw at
the last meeting, wish it had come earlier).

In <1993Dec30.162634.1493@datascope.com> sfc@datascope.com (Steve F. Cipolli (P/M)) writes:

(other material editted out)

>Thank you for stating what I've been wanting to say from the moment I began
>reading about the new boolean type.  What I'd like to add is several leading
>questions.
>
> 1) Why does this proposal attempt to accomodate keyword conflicts
> when no previous proposal has set such a precedent?  Anyone who had
> a variable/type/class called "template", "try", etc ... was/is
> out-of-luck with the recent additions to C++.

Actually, the introduction of a new keyword is _always_ taken seriously by
the committee.  Please note that a keyword representing a type is much more
likely, if chosen poorly, to cause a large number of conflicts than one
that may be used as a variable name in a few programs, especially if that
type is intended to eventually replace one used in common libraries and
header files.


> 2) Why is the C++ committee supporting backward compatibility to
> practices that are at least confusing, and at most potentially buggy?
> I refer to the use of ++ on boolean objects.  In the former, its
> obvious from this thread that no one can agree on how it should work,
> and in the latter, the overflow case pointed out earlier gives me
> chills (a bug that could take years to appear).  Such practices should
> be made impossible to perform in a language, not accomodated.

I suspect the overflow case is fairly uncommon.  I personally would want an
(optional, on by default) warning from my compiler, but this is a quality
of implementation issue.  I will not defend ++, but I did not vote against
the proposal simply because it included this (and folks, it's not too late
to change)

> 3) Why is the C++ committee so worried about breaking C++ code while
> it is still in the early stages of standardization?  While I applaud
> the effort to avoid conflicts, I tend to draw the line when it is
> going to alter the final language standard in non-intuitive ways.

The (draft) standard is not in the early stages of creation.  We all hope
that the vast majority of C++ code is still to be written, but (and this
is in my mind - perhaps not others) there are projects that get ported from
ISO C to C++.  This increases the potential body of "dusty decks" out there.
I myself often port C -> C++ for one reason - mandatory function prototypes.

What are you worried about non-intuitivity in? the names chosen?  Operator++?
the existence of a bool type?

> 4) Isn't the current state of C++ difficult enough for new-comers to
> grasp?  C++ already has a number of "remember that this works like this
> because that".

As does C, only in C it's more likely to be an obscure gotcha.  In any
computer language, most people tend to gravitate to a subset that they feel
comfortable with.  I never use member pointers, for example.  Newcomers,
particularly from a non-object-oriented background, take some time in
really getting up to speed in C++.  I took a year or more.  I programmed in
it first day, and was capable of as complex programs as I ever did in C -
because I _was_ _still_ _programming_ _in_ _C_.  Some features have to be
learnt at the beginning (classes, overloading), and others get introduced with
time.  A new type is not an essential feature, and thus fairly easy to
grasp incrementally.

>Is it worth adding more caveats to the language just so a few people don't
>have to do a search and replace on the bool keyword?  BTW if this is such a
>major problem, the compiler could handle this with a simple command line
>switch.

It really does seem as if your main complaint is with operator++.  This is
valid, but I want to point out you haven't really been arguing against
a bool type per se.

>-Stephen

-simon

===============================================================================
Simon Tooke  (not speaking for) SCO Canada, Inc.         Voice:  (416) 922-1937
....!scocan!simon             simon@sco.com                Fax:  (416) 922-2704
130 Bloor St. West. Suite 1001, Toronto, Ontario, Canada  M5S 1N5

In article <2g3mde$5vi@urmel.informatik.rwth-aachen.de> dak@messua.informatik.rwth-aachen.de (David Kastrup) writes:

>As the proposal now stands, in the form that it uses, bool would be
>almost not distinguishable from
>typedef int bool;
>#define true 1
>#define false 0

You pointed one important difference.  Here's another: in C,
the value of, say, isupper('X')==true is implementation defined
because isupper('X') is permitted to return any nonzero value.
If isupper is defined to yield a bool, as C++ presumably will do,
then this whole class of pitfall will go away.
--
    --Andrew Koenig
      ark@research.att.com

In article <CJ817p.D02@microsoft.com> jimad@microsoft.com (Jim Adcock) writes:

>In article <CJ5tAB.9o7@tempel.research.att.com> ark@tempel.research.att.com (Andrew Koenig <9577-82971> 059113A) writes:
>|In article <CJ4Fuo.DJt@microsoft.com> jimad@microsoft.com (Jim Adcock) writes:
>|
>|>The concept that bools should implicitly bidirectionally coerce
>|>to/from ints does not exist in other languages.  Particularly
>|>in languages with overloading and implicit constructors/
>|>coercion operators.  My concern is with the extent to which
>|>coercion ambiguities are being added to the language.
>|
>|The concept that chars should implicitly bidirectionally coerce
>|to/from ints does not exist in other languages.  Particularly
>|in languages with overloading and implicit constructors/
>|coercion operators.
>|
>|The concept that floats should implicitly bidirectionally coerce
>|to/from ints does not exist in other languages.  Particularly
>|in languages with overloading and implicit constructors/
>|coercion operators.
>
>These other admittedly questionable bidi conversions 1) have already
>existed, so they are not being ADDED to the language, the affect
>of such additions being one of many issue you and Dag fail to
>analyze in your proposal, and 2) they are not related to bools,
>which was the original posters question.

Jim Adcock is correct, in that I had asked for *any* concepts
that are unique to C++.  It is unfortunate that it was seen as an
opportunity to fire a volley to the bool type supporters camp ;-)

Personally, I agree that *by analogy*, the ``concept of implicit
and bidirectional coercion of bools and ints'' does exist in (at
least) C, a predecessor language to C++. (*NOTE* analogue to char/int,
and float/int.)

So far, I have heard of one concept, that of user supplied
destructors, that is unique to C++.

Sincerely
Skip
--
    ********************************************************************
    *  Fariborz ``Skip'' Tavakkolian Claircom Communications Group  *
    *  fst@claircom.com   700 Fifth Ave, Suite 2100      *
    *  (206)389-7150   Seattle, WA.  98104            *
    ********************************************************************

In <comp.std.c++> joga@ppls1c217.ppvlu (Johan Garpendahl) writes:
>
>What would happen if the bool type was part of a standard library
>instead of a built-in type? It would still be possible to do the
>desired overloading, and it would be possible to decide not to use it
>for those who don't like it.

The key question is: do you want "x > 3" to return bool?  If the
answer is yes, you must change the basic language.

    -- Dag

In article <BRUCE.94Jan10151044@cmsr3.liverpool.ac.uk> bruce@liverpool.ac.uk writes:
>>
>> Why not introduce keyword 'bool' with the same status as 'signed'? Why not
>> allow:
>
>> bool b; //int is implicit

   Nah. int's usually take 4 bytes, where just one bit is needed. Wasteful.

>> bool long b4; //Well, maybe I want to add all the true flags to a long int> sum!

>I don't see what "bool int", "bool char", etc., are supposed to mean.
>As far as I can see, they are meaningless.  As meaningless as char int.

   Packed bit arrays? Interesting idea at the language level, quite useful for
real low-level, I/O-register-orientated programming, drivers and stuff.

                                                          -Henrik
--
Beorn's house - run by Henrik Clausen <hclausen@beorn.ping.dk>

In article <2gr0q3$2gm@ppls1c217.ppvlu> joga@ppls1c217.ppvlu (Johan Garpendahl) writes:

> What would happen if the bool type was part of a standard library
> instead of a built-in type?

Then it would be hard to understand how the type of expressions
like 3<4 could be expressed.
--
    --Andrew Koenig
      ark@research.att.com

In article <CJFp16.EHJ@tempel.research.att.com> ark@tempel.research.att.com (Andrew Koenig) writes:

> > What would happen if the bool type was part of a standard library
> > instead of a built-in type?
>
> Then it would be hard to understand how the type of expressions
> like 3<4 could be expressed.

Not *that* hard.  Expressions like 3<4 would continue to return ints,
as they do now.  That's not terribly different from making these
expressions return bools, but allowing conversion between bools and
ints.

There are a few places where you can tell the difference between these
two possibilities, but not all that many.  The most obvious is if
you've defined both f(int) and f(bool), and you call f(3<4).

For the record, I think that the proposal that was adopted, i.e.,
making bool a new built-in type, is a bit better than making bool a
class defined in the standard class library.  I also think, though,
that the difference between those two possibilities isn't all that
important.
--
Matthew Austern                       Never express yourself more clearly
matt@physics.berkeley.edu             than you think.    ---N. Bohr

>>>>> On Sun, 9 Jan 1994 08:19:46 GMT, rfg@netcom.com (Ronald F. Guilmette) said:

rfg> It seems that in all facets of modern life (including language
rfg> standardization) there is always an abundance of folks (e.g. the
rfg> Moral Majority) who are damn certain that they know just what's
rfg> best for everyone else, and who are more than ready to enact
rfg> laws, rules, regulations, etc., to insure that everyone else
rfg> lives up to their own high ideals.

This is just plain silly. I'm certain that the proposal for a bool
type is from the genuine desire to eliminate the current library
conflicts and because they personally desire to use it.

I think that you've made your main objections more than clear. You
don't want *any* language extensions before there's a codified
language standard other than the ARM. I understand. I understood many,
many messages ago.  It's a resonable point of view. I don't happen to
share it, but it's certainly reasonable.

Since you apparently feel so strongly about this, you should (and
obviously do) feel free to try to persuade us. But I would hope that
you could allow people to disagree with you without suggesting such
absurd motivations.

rfg> If `bool' (or any other "late" extension) is really that great,
rfg> then why not just wait for Borland, Microsoft, USL, IBM, and
rfg> everyone else to add it to their compilers on their own?  Why
rfg> force it down everyone's throat by making it a required part of
rfg> the base standard?

On a slightly more technical note, I would consider a plethora of
incompatable language extentions to be a very large failure in the
standardization efforts.

 Hayden
--
Hayden Schultz
haydens@ll.mit.edu
MIT Lincoln Lab
244 Wood St.
Lexington, MA, 02173
(617) 981-3685

In response to my message (not published here, by mistake), Andrew Konig writes:

>MGA> I've seen frequent reference to the idea of "deprecated" features of the
>MGA> language.  Is the concept of a "deprecated" feature part of the standard, or is
>MGA> it an informal comment that can be freely interpreted or ignored by any
>MGA> implementor?
>
ARK> It is not part of the standard at present, but almost surely will be.
ARK> The idea is that anything marked as deprecated is potentially able to
ARK> be deleted in the next version of the standard.  Moreover, implementations
ARK> are required to provide a mode whereby they give a diagnostic message
ARK> for all deprecated features.

>MGA> If "deprecation" were to be part of the standard, then we would have two
>MGA> separate languages being defined - an "inner" or core language, free of
>MGA> deprecated features, being a subset of an "outer" or full language, which
>MGA> implements everything.
>
ARK> The committee isn't keen on subsets generally.  The idea is that
ARK> deprecated features are permitted, but just barely and you shouldn't
ARK> use them if you have a choice.

>MGA> Given a formal role for deprecation of features, surely this would resolve many
>MGA> of the arguments about this type.  Purists can then argue about the core type -
>MGA> I would like to see any conversion between int and bool as deprecated.
>MGA> Pragmatists can allow bool to be an integer type.
>
ARK> The trouble is the common usage:
ARK>  if (p) *p = q;

>MGA> The only thing is, we'll need compilers to support both varieties, with a
>MGA> warning level to block all deprecated features.  Surely this is a good thing?
>
ARK> I don't understand how a standard can tell implementations to block
ARK> anything.  The most they can do is require a diagnostic message.


In response, I would like to say:

If deprecation goes into the standard and implementations provide a
mode where deprecated features generate warnings, then I would like to argue that
this does define a subset.  For example, I always compile with "warnings are
errors" set as a compiler option - thus, I restrict myself to the language subset
which doesn't generate warnings.

The point is, if deprecation is to be used coherently then it can be used to
define a sub-language which is free from some of the more unfortunate "freedoms"
of C(++).  Obviously there is a *vast* amount of room for argument about what
should (and should not) be deprecated - for this note, I'll assume this argument
isn't fatal to the idea of a sublanguage :-) (wild optimism, here)
    I guess it depends very much where the committee hopes C++ is going.
Personally I would like to see most of the backward compatibility features as
"deprecated" features (eg, get rid of default typing to int, make bool a classical
boolean type *without* conversion to and from integer, etc) - but perhaps I'm
using the wrong language?  (I'm not starting that conversation here.)
    In particular, it seems to me that allowing 'if(p)*p=q;' is a backwards
compatibility feature, and the "proper" (more "honest") idiom is actually

 if ( p != NULL )  *p = q;

In article <MATT.94Jan10193824@physics2.berkeley.edu> matt@physics.berkeley.edu writes:

> There are a few places where you can tell the difference between these
> two possibilities, but not all that many.  The most obvious is if
> you've defined both f(int) and f(bool), and you call f(3<4).

Exactly.  Without that case, there's no point in bothering.
--
    --Andrew Koenig
      ark@research.att.com

In article <a3yMtAIGBh107h@rcp.co.uk> michael@rcp.co.uk (Michael Abbott) writes:
>
>If deprecation goes into the standard and implementations provide a
>mode where deprecated features generate warnings, then I would like to argue that
>this does define a subset.  For example, I always compile with "warnings are
>errors" set as a compiler option - thus, I restrict myself to the language subset
>which doesn't generate warnings.
>
>The point is, if deprecation is to be used coherently then it can be used to
>define a sub-language which is free from some of the more unfortunate "freedoms"
>of C(++).  Obviously there is a *vast* amount of room for argument about what
>should (and should not) be deprecated - for this note, I'll assume this argument
>isn't fatal to the idea of a sublanguage :-) (wild optimism, here)
>    I guess it depends very much where the committee hopes C++ is going.
>Personally I would like to see most of the backward compatibility features as
>"deprecated" features (eg, get rid of default typing to int, make bool a classical
>boolean type *without* conversion to and from integer, etc) - but perhaps I'm
>using the wrong language?  (I'm not starting that conversation here.)
>    In particular, it seems to me that allowing 'if(p)*p=q;' is a backwards
>compatibility feature, and the "proper" (more "honest") idiom is actually
>
> if ( p != NULL )  *p = q;

I have always felt that your "proper and more honest" idiom is actually
syntactic sugar.  'if (p) *p = q;' (with proper indentation of course)
is one of the things that I liked about C (and now C++) over other languages.
I will be very disappointed if this code generates a warning or an error.
'if (p != NULL) *p = q;' gives me the impression that the coder doesn't
understand the concept of zero is false and non-zero is true.

Stephen Gevers
sg3235@shelob.sbc.com

>> if ( p != NULL )  *p = q;
>I have always felt that your "proper and more honest" idiom is actually
>syntactic sugar.  'if (p) *p = q;' (with proper indentation of course)
>is one of the things that I liked about C (and now C++) over other languages.
>I will be very disappointed if this code generates a warning or an error.
>'if (p != NULL) *p = q;' gives me the impression that the coder doesn't
>understand the concept of zero is false and non-zero is true.
>Stephen Gevers
>sg3235@shelob.sbc.com
But, but, but! You do not seem to understand that null pointers may be
non zero. This is implementation dependent, as every 'coder' should
understand.
Jon


Dream for a world the way you want it. Accept the world the way it is.
squire@cs.umbc.edu

In article <MATT.94Jan10193824@physics2.berkeley.edu> matt@physics2.berkeley.edu (Matt Austern) writes:
>In article <CJFp16.EHJ@tempel.research.att.com> ark@tempel.research.att.com
(Andrew Koenig) writes:

>> > What would happen if the bool type was part of a standard library
>> > instead of a built-in type?
>>
>> Then it would be hard to understand how the type of expressions
>> like 3<4 could be expressed.

>Not *that* hard.  Expressions like 3<4 would continue to return ints,
>as they do now.  That's not terribly different from making these
>expressions return bools, but allowing conversion between bools and
>ints.

>There are a few places where you can tell the difference between these
>two possibilities, but not all that many.  The most obvious is if
>you've defined both f(int) and f(bool), and you call f(3<4).

I keep seeing this as an argument for bool being a built-in type instead of in
the standard library, and I have to wonder why would anyone want to? Why would
I want a function that accepts either ints or bools and behaves differently?

I can't see throwing the English words True and False into the iostream
library, so the only logical things for it to print are 0 and 1 anyway because
they were converted to int. I tend to overload the meaning of bool anyway so I
want different things printed for each variable anyway, sometimes Yes/No or
Male/Female or .....

The only other use that I can see is to allow a collection class to compact
bools instead of storing them as ints. Even then I don't see where having bool
defined as a built-in type makes things any easier.

So, can anyone tell me why I would WANT to overload bool?

I am not against bool as a built-in type, I want all the type-checking I can
get, and I think compilers will be eventually be able to do better
type-checking with bool as a built-in type, I just get sick of hearing
overloading as a reason for bool being a built-in type.

Thanx,
Ralph

>Stephen Gevers
>sg3235@shelob.sbc.com
>
>'if (p != NULL) *p = q;' gives me the impression that the coder doesn't
>understand the concept of zero is false and non-zero is true.

Zero isn't false: zero is an integer and false is a boolean.  Of course,
C(++) has chosen to treat zero as false, but that is just one of the
language's quirks.  I guess it all depends where you start from.

squire@umbc.edu (Mr. Jon S. Squire) writes:

>>> if ( p != NULL )  *p = q;
>>I have always felt that your "proper and more honest" idiom is actually
>>syntactic sugar.  'if (p) *p = q;' (with proper indentation of course)
>>is one of the things that I liked about C (and now C++) over other languages.
>>I will be very disappointed if this code generates a warning or an error.
>>'if (p != NULL) *p = q;' gives me the impression that the coder doesn't
>>understand the concept of zero is false and non-zero is true.
>>Stephen Gevers
>>sg3235@shelob.sbc.com
>But, but, but! You do not seem to understand that null pointers may be
>non zero. This is implementation dependent, as every 'coder' should
>understand.
>Jon

Pointers may be represented as something other than binary zero internally,
but they will compare equal to 0 and will result in 0 when converted to an
integer type.  In most cases a null pointer is indistinguishable from 0.

Surely you don't intend that "if (p)" would now mean something different
from "if (p != 0)".

And I didn't call you Shirley :-)
--
Kevin J. Hopps   e-mail: kjhopps@mmm.com
3M Company   phone: (612) 737-3300
3M Center, Bldg. 235-3B-16 fax: (612) 737-2700
St. Paul, MN 55144-1000

In article <trickr.45.0010524A@uh2372p03.daytonoh.ncr.com>,
Ralph Trickey <trickr@uh2372p03.daytonoh.ncr.com> wrote:

>I can't see throwing the English words True and False into the iostream
>library

If the C++ standard follows the C standard, "true" and "false" could change
according to the locale.

--
    John Carr (jfc@mit.edu)

Andrew,

I have been following the bool discussion with considerable
interest, if not always enough time to keep up with the traffic.
Thank you for making so much effort to explain.

Is there a bool class that is considered state-of-the-art short
of a compiler extension? It would help me to be clearer if I
could see exactly where defining a standard bool.h library is
inadequate.

I know there has been considerable philosophical discussion along
these lines, but perhaps others have come up with a different way
of handling bool right now than what I have seen. Does anyone
have a bool.h library?

Robin
--
---------------------------------------------------------
Robin Rowe    Rowe Techology | Flamers and complainers:
rrowe@halcyon.com            |  If you have nothing to
Northwest C++ Users Group    |   contribute please don't.

>>>>> On 12 Jan 94 13:38:19 GMT, sg3235@sw1sta.sbc.com (Stephen Gevers) said:

Stephen> I have always felt that your "proper and more honest" idiom
Stephen> is actually syntactic sugar.  'if (p) *p = q;' (with proper
Stephen> indentation of course) is one of the things that I liked
Stephen> about C (and now C++) over other languages.  I will be very
Stephen> disappointed if this code generates a warning or an error.
Stephen> 'if (p != NULL) *p = q;' gives me the impression that the
Stephen> coder doesn't understand the concept of zero is false and
Stephen> non-zero is true.

I think it's more important to consider the reader of the code rather
than the writer of the code. if(p != NULL) indicates to the reader
that p is being used like a pointer. if(p) means that the reader has
to know a lot more about the type p before it's really understood.

Besides, a spoonful of syntactic sugar makes the medicine go down.

There are two big reasons I like the bool proposal. The first is
because I'm sick and tired of library bool conflicts. The second is
that I find it convinient to have an operator int() and an operator
bool(). bool and an int don't have the same meanings at all.

 Hayden
--
Hayden Schultz
haydens@ll.mit.edu
MIT Lincoln Lab
244 Wood St.
Lexington, MA, 02173
(617) 981-3685

>>>>> On 11 Jan 94 21:19:10 GMT, trickr@uh2372p03.daytonoh.ncr.com (Ralph Trickey) said:

Ralph> I keep seeing this as an argument for bool being a built-in
Ralph> type instead of in the standard library, and I have to wonder
Ralph> why would anyone want to? Why would I want a function that
Ralph> accepts either ints or bools and behaves differently?

The biggest reason I find is constructors.

class A {
  A(int);
  A(bool);
};

To do this now, I've got to either typedef bool to a non int, make an
enum, or a class. And whatever I choose, it's going to conflict with
anyone who uses the name bool and makes a different decision. The most
frustrating case of all is when I use two existing libraries which
each use two different solutions for bool-- then it's not my fault at
all.

 Hayden
--
Hayden Schultz
haydens@ll.mit.edu
MIT Lincoln Lab
244 Wood St.
Lexington, MA, 02173
(617) 981-3685

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

>In <comp.std.c++> rfg@netcom.com (Ronald F. Guilmette) writes:
>>
>>Several people (including myself) have here questioned both the need for,
>>and the details of this whole `bool' idea.  I think that indicates something
>>in and of itself.

I think it indicates that people are concerned about a major change to the
language.

>Ron, you were present at the standards meeting in San Jose where the
>proposal was discussed and accepted.

>Why didn't you speak up at the meeting, instead of hashing it all over
>on the net after it was accepted?

>Why didn't you talk to me and raise your concerns when I was there?

>As you said yourself: "I think that indicates something in and of
>itself."  I think your attitude is unserious.

Personally, I salute the work of all those on the committee, and those
who worked on the bool proposal in particular.  I think it takes great
courage to suggest a major change, whether or not that change is a good
idea (and reasonable people can disagree on what is a good idea).

Can we please get past the personal sniping and talk about the issues?

Dag, your time and effort has been valuable and courageous, regardless
of the outcome, and regardless of whether people like it.  And [the substance
of] Ron's criticism needs to be taken seriously regardless of the relative
seriousness of his attitude.

Ron, I appreciate your thoughts and criticisms.  Your time and effort here
is also valuable.  I have personally noticed much thought in your postings
over the several months I have been listening to news from this group.  Please
keep up the effort.  I'm sure many find it valuable.

Now for my own $.02, I'd say that I basically like the bool idea.  It would
have saved much time over the years of participating in the generation of
coding guidelines and standards if an authority could have settled the
question of what type a boolean value should be, what its name should be, etc.
(While this has been for C, similar arguments occur wrt C++).
I don't like allowing ++ on booleans, even for the benefit of existing code.
Seems to me that to find the x++'s and change them to x=true's will require
not much effort at all (editing can be semi-automated in many cases), and
certainly not much _more_ effort than that required to adjust for the changes
in keywords.

Regardless of the ultimate decisions wrt ++ and other operators and
conversions, I am fairly comfortable in letting the committee weigh the
consequences of its own actions (assuming its members pay attention to
the net traffic and consider the criticisms and comments seriously) and
make the decisions that seem right.
--
Kevin J. Hopps   e-mail: kjhopps@mmm.com
3M Company   phone: (612) 737-3300
3M Center, Bldg. 235-3B-16 fax: (612) 737-2700
St. Paul, MN 55144-1000

Andrew Koenig <9577-82971> 059113A (ark@tempel.research.att.com) wrote:
: You pointed one important difference.  Here's another: in C,
: the value of, say, isupper('X')==true is implementation defined
: because isupper('X') is permitted to return any nonzero value.

That is why I started to use only "!= false" like statements in about any
language I had to do work in, because I knew they all used 0 as false. ;^)

:                               --Andrew Koenig

--
Heinz Wrobel        Edotronik GmbH: heinz@edohwg.adsp.sub.org
                    Private Mail:   heinz@hwg.muc.de
My private FAX: +49 89 850 51 25, I prefer email

dag@control.lth.se (Dag Bruck) writes:
 } In <comp.std.c++> sfc@datascope.com (Steve F. Cipolli (P/M)) writes:
 } >
 } > 1) Why does this proposal attempt to accomodate keyword conflicts
 } > when no previous proposal has set such a precedent?
 }
 } There is precedent.  Many libraries define a boolean type, which
 } causes considerable problems when libraries are mixed.  One of goals
 } of the proposal is to get rid of this mess by agreeing on one name for
 } the Boolean type: "bool."

I'd expect the problem of mixing libraries to be greatly reduced by
namespaces. If both libraries and encapsulated within namespaces,
possible with using declarations, then uses of "bool" become
ambiguous and must be explicitly qualified. It should work.
--
Daniel R. Edelson     | ``Shh. This is my favorite deodorant commercial.''
daniel@lia.com        |                                      - Calvin
IA Corp, Alameda, CA  |

ark@tempel.research.att.com (Andrew Koenig) writes:

 } I don't think C++ is any more difficult to grasp than any other commonly
 } used programming languages, provided it is well taught.  It is probably
 } somewhat easier to teach poorly than other languages because it doesn't
 } come with built-in clues as to how to use it.

Except that
    1) C++ is more complicated than most languages
    2) Past/current language definitions leave much unsaid
       (in the slow process of rectification)

Consider anonymous unions for example. While they're a small feature,
they introduce a bunch of special rules, for example:
    - global anonymous unions must be declared static
    - anonymous unions may not have function members
    - anonymous unions may not contain access specifiers
    - a union with a declared variable or pointer isn't anonymous
    - members must be unique w.r.t names declared in the enclosing scope

I like anonymous unions as a feature, but I think C++ would have been
simpler without them. Whether or not this is compelling depends on
your point of view.  Otherwise, it probably would have been better not
to lump unions in with classes and structures, i.e., define C++ unions
to be exactly like C unions (no member functions). This also would
have simplified the language nontrivially. Oh well, too late now.
--
Daniel R. Edelson     | ``Shh. This is my favorite deodorant commercial.''
daniel@lia.com        |                                      - Calvin
IA Corp, Alameda, CA  |

In article <rfgCIsE6G.Bvn@netcom.com>, rfg@netcom.com (Ronald F. Guilmette) writes:

> >> The point is to be able to remove the `typedef int bool;' declaration
> >> and have this program still work.
> >> --
> >>     --Andrew Koenig
> >>       ark@research.att.com
> >
> >IMHO, programs like this deserve to be broken! If someone uses booleans
> >he should use them right.

> I agree, and I think this point illustrates a lot of what has gone wrong
> with the ``design by committee'' that's been going on the C++ standardization
> committee.  Those folks have gone to great lengths to preserve a huge number
> of ancient language warts, ostensibly for the sake of maintaining old legacy
> code (a consideration which is, after all completely irrelevant to this
> discussion on the bool type, but I digress).  I haven't noticed the
> committee ever questioning the wisdom of maintain code which was brain-
> damaged to begin with.

Actually, the phrase ``code which does X should be taken out and shot'' in
committee correspondence is a common and fairly reliable indicator of such
things.
--
 (This man's opinions are his own.)
 From mole-end    Mark Terribile
 mat@mole-end.matawan.nj.us, Somewhere in Matawan, NJ
 (Training and consulting in C, C++, UNIX, etc.)

Heinz Wrobel (heinz@hwg.muc.de) wrote:

[...]

: That is why I started to use only "!= false" like statements in about any
: language I had to do work in, because I knew they all used 0 as false. ;^)

Thats poor style, too. You should use "b" instead of "b == true"!
Or would you also write:

if (NULL == p) b = true;

instead of:

b = (NULL == p);

?

: Heinz Wrobel        Edotronik GmbH: heinz@edohwg.adsp.sub.org
:                     Private Mail:   heinz@hwg.muc.de
: My private FAX: +49 89 850 51 25, I prefer email


Lars With
Merken & With Consulting
Winterfeldtstr. 94
10777 Berlin
Tel./Fax (030) 211 82 20

In article <2g3mde$5vi@urmel.informatik.rwth-aachen.de> dak@messua.informatik.rwth-aachen.de (David Kastrup) writes:

>As the proposal now stands, in the form that it uses, bool would be
>almost not distinguishable from
>typedef int bool;
>#define true 1
>#define false 0
>in case you were using C, so C never needed a saparate bool, although
>many people were muddling the concepts of boolean and integral types
>(like x++), and this is (in my opinion) bad style not to be encouraged.
>
>However, in C++, there is one additional reason for wanting bool:
>So that
>cout << (i>3)
>might deliver something like
>true
>    or
>false
>instead of 0 or 1. In short, one might to want to overload.
>

I am going to open a can of worms here: When I first used C++, I thought that
C++ would differentiate between two typedefs.  I was disappointed when I found
that it wouldn't work.  It would be nice if there existed a keyword that would
actually become a new type (sort of like typedef).  This way, overloading
could be done on things like pid_t, size_t, etc.  Furthermore, types could be
converted to what they are typedef'd to, but not the other direction without
an explicit cast. For example:

 typedef int pid_t;
 typedef int size_t;
 size_t strlen (char *);
 ostream &operator<< (ostream &o, const pid_t &p) {
  return o << "Process Id: " << p;
 }
 pid_t pid;

 pid = strlen ("hello world"); // works now, but could be illegal
 pid = (pid_t) strlen ("hello world"); // I'm aware of the conversion
 cout << p << endl;

This would also solve the bool overloading problem (sort of) with the following
code:
 cout << (bool) (i<3);

where there exists the function ostream &operator<< (ostream &o, bool b) and
a typedef int bool.  Granted it takes a cast, but it gives the ability to
overload.  Since a bool will automatically convert to integer, existing code
will continue to work as coded.  The bool will be converted (and actually there
is no real conversion needed) to int for any function call which expects an
int and receives a bool.

I haven't thought of all of the caveats of this suggestion, but I would like
to hear what everyone things of it.  Flames are welcome!

>
>The current proposal wants to obtain this, while maintaining immediate
>workability of existing programs, up to a certain empirical measure
>(determined by how often seen) of brain-damagedness.
>
>However, it seems that when replacing typedef int bool; by nothing,
>it should not appear to be too complicated to replace all instances
>of x++, or of several other bad practices by the appropriate
>counterparts, when being noted by the compiler.
>
>
>Such changes would appear to be rather trivial, so maybe the point
>of brain damage support might be debatable, since we all in the long
>run would like to have a language standard not using too many
>square meters of paper and cells of brain in order to remember.
>--
> David Kastrup        dak@pool.informatik.rwth-aachen.de
> Tel: +49-241-72419 Fax: +49-241-79502
> Goethestr. 20, D-52064 Aachen

Stephen Gevers
sg3235@shelob.sbc.com

Simon Tooke (simon@sco.COM) wrote:
: It really does seem as if your main complaint is with operator++.  This is
: valid, but I want to point out you haven't really been arguing against
: a bool type per se.

I am for the proposed bool type, not for the compatibility and its complexity.

-Stephen

Andrew Koenig <9577-82971> 059113A (ark@tempel.research.att.com) wrote:
: In article <1993Dec30.162634.1493@datascope.com> sfc@datascope.com (Steve F. Cipolli (P/M)) writes:

: > 1) Why does this proposal attempt to accomodate keyword conflicts
: > when no previous proposal has set such a precedent?  Anyone who had
: > a variable/type/class called "template", "try", etc ... was/is
: > out-of-luck with the recent additions to C++.

: It doesn't.  It adds three new reserved words: bool, true, and false.
: If you try to use those words for any other concepts, you're out of luck.

As the previous writter had stated (para-phase) "No code exists with bool
and ++.  It only exists where the soon-to-be keyword "bool" conflicts with
a typedef.  Any keyword added to C++ in the recent past (ie. template), could
as easily conflicted with existing code typedefs/classes/variables.  So why
the special treatment for bool.

: > 2) Why is the C++ committee supporting backward compatibility to
: > practices that are at least confusing, and at most potentially buggy?
: > I refer to the use of ++ on boolean objects.  In the former, its
: > obvious from this thread that no one can agree on how it should work,
: > and in the latter, the overflow case pointed out earlier gives me
: > chills (a bug that could take years to appear).  Such practices should
: > be made impossible to perform in a language, not accomodated.

: Because the practice is exceedingly widespread among C and C++ programmers,
: the proposal accommodates it temporarily as a transition aid.  The intend is
: to remove ++ on bool values in the next version of the standard.

I have never seen this happen in practice.

: > 3) Why is the C++ committee so worried about breaking C++ code while
: > it is still in the early stages of standardization?  While I applaud
: > the effort to avoid conflicts, I tend to draw the line when it is
: > going to alter the final language standard in non-intuitive ways.

: Because if the standard breaks too much existing code, vendors will
: simply ignore it.

I do not think this is true, at least not any more.

: > 4) Isn't the current state of C++ difficult enough for new-comers to
: > grasp?  C++ already has a number of "remember that this works like this
: > because that".

: I don't think C++ is any more difficult to grasp than any other commonly
: used programming languages, provided it is well taught.  It is probably
: somewhat easier to teach poorly than other languages because it doesn't
: come with built-in clues as to how to use it.

C++ is a great language, but I wouldn't say it is as easy to learn as other
common languages.  I don't have the time or energy at the moment to give
chase to this debate.  Again, I do really like the language.

: >Is it worth adding more caveats to the language just so a few people don't
: >have to do a search and replace on the bool keyword?  BTW if this is such a
: >major problem, the compiler could handle this with a simple command line
: >switch.

: Not if the standard doesn't allow it and the compiler vendor wishes to
: conform to the standard.  That's exactly the point.
: --
:     --Andrew Koenig
:       ark@research.att.com

-Stephen

In article <FST.93Dec31115100@nimo.claircom.com> fst@nimo.claircom.com (Fariborz Skip Tavakkolian) writes:
>In article <rfgCIsF44.D7D@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:
|
|>  There is an old saying that a camel is a horse which was designed
|>  by committee.

|Are you suggesting that camels are bad?  For those of us who are from
|that part of the world, this is a very sensitive issue :-)

Not that camels are bad, simply that they are bad horses.

And when a committee designs a camel with three humps, then
its even a bad camel.

|In a previous posting you suggested that language is becoming
|experimental (``designed in a lab'').  Could someone name a
|concept in the language (C++) that does not exist in another
|(predecessor) language?

The concept that bools should implicitly bidirectionally coerce
to/from ints does not exist in other languages.  Particularly
in languages with overloading and implicit constructors/
coercion operators.  My concern is with the extent to which
coercion ambiguities are being added to the language.

In article <1994Jan01.140706.20064@sco.COM> simon@sco.COM (Simon Tooke) writes:
|It really does seem as if your main complaint is with operator++.  This is
|valid, but I want to point out you haven't really been arguing against
|a bool type per se.

Clearly the argument is not against any 'bool' type but rather the
proposed change in implementation.  C/C++ always had a 'bool' type,
its just that the distincness of that implementation was so weak that
the implementation merged it with 'int'.  The new proposed changes remain
almost as weak, what with the bidi autoconversions to/from int.  This
allows new keywords to be introduced with almost no new advantages to
those keywords, and while allowing additional type ambiguities.  Thus
the language is changed to have a new 'bool' type without having [hardly] any
advantages to that type.

As a strawman counterproposal, how about if we bite the bullet, have a
'real' bool type WITHOUT the implicit coercion back from int to bool,
and let people fix the code which is currently busted?  Compilers could
still implement the implicit coercion from int->bool as a deprecated
backwards compatibility feature -- at the expense of issuing a warning.
IMHO this is much better than having many compilers issuing warnings
for legal code -- which many people have been arguing is a'feature'
of the current proposal.  On the contrary, issuing warnings on legal
code is a BUG, not a feature.  The necessity of doing so represents
either a bug in the language definition, or in the compiler.  A
central example in this debate is:

 int i,j;

 while (i = j)
  dosomething();


The current proposal continues to support this, at the cost of allowing
implicit coercions from int->bool.  Many compilers then issue warnings
about this 'legal' construct.  My counterproposal would make this
illegal, unless an explicit coercion were introduced:

 while (bool(i = j))

Old code that said:

 while (i = j)

would then *legitimately* at least generate a backward compatibility
warning.  A further advantage of this counterproposal is that it would
continue to allow a reasonable type hierachy:

bool -> char -> short => int => long

verses the current [rather strange] proposal:

bool -> char -> short => int => long
 ^                        |
 |                        |
 +------------------------+

In <comp.std.c++> jimad@microsoft.com (Jim Adcock) writes:
>
>As a strawman counterproposal, how about if we bite the bullet, have a
>'real' bool type WITHOUT the implicit coercion back from int to bool,
>and let people fix the code which is currently busted?  Compilers could
>still implement the implicit coercion from int->bool as a deprecated
>backwards compatibility feature -- at the expense of issuing a warning.

It's hardly a strawman, because that is what Andy and I originally
proposed (and the committee changed).  If anyone would like to propose
a change back to the original proposal, that's fine with me and I will
support it.

>Old code that said:
>
> while (i = j)
>
>would then *legitimately* at least generate a backward compatibility
>warning.

Exactly.

   -- Dag

In article <1994Jan4.203532.2192@datascope.com> sfc@datascope.com (Steve F. Cipolli (P/M)) writes:

>As the previous writter had stated (para-phase) "No code exists with bool
>and ++.  It only exists where the soon-to-be keyword "bool" conflicts with
>a typedef.  Any keyword added to C++ in the recent past (ie. template), could
>as easily conflicted with existing code typedefs/classes/variables.  So why
>the special treatment for bool.

What special treatment?


>: Because the practice is exceedingly widespread among C and C++ programmers,
>: the proposal accommodates it temporarily as a transition aid.  The intent is
>: to remove ++ on bool values in the next version of the standard.

>I have never seen this happen in practice.

Neither have I, because neither C nor C++ has gone into the second version
of its standard.  We won't know whether it's possible to removge things
from a standard until we try, and that will probably be a decade or so
from now, but at least we intend to leave open the possibility.

Or did I misunderstand you?  You seem to be saying that you had never seen
a feature removed from a subsequent version of a standard, and I agree.
If instead you were saying you have never seen ++ applied to a Boolean
value, all I can say is that I have, many times.  The typical usage is

 bool aflag, bflag, cflag;

 /* ... */

  switch(option) {
  case 'a': aflag++; break;
  case 'b': bflag++; break;
  case 'c': cflag++; break;
  default: complain();
  }

>: Because if the standard breaks too much existing code, vendors will
>: simply ignore it.

>I do not think this is true, at least not any more.

Examples of languages standards that have been ignored for precisely that
reason include PL/I and Pascal.  Remember, Pascal was the dominant system
programming langauge on DOS machines for quite a while -- not exactly
an unpopular language.  But because the Pascal standard did not reflec
actual usage, vendors ignored it.

--
    --Andrew Koenig
      ark@research.att.com

In article <CJ4Fuo.DJt@microsoft.com> jimad@microsoft.com (Jim Adcock) writes:

>The concept that bools should implicitly bidirectionally coerce
>to/from ints does not exist in other languages.  Particularly
>in languages with overloading and implicit constructors/
>coercion operators.  My concern is with the extent to which
>coercion ambiguities are being added to the language.

The concept that chars should implicitly bidirectionally coerce
to/from ints does not exist in other languages.  Particularly
in languages with overloading and implicit constructors/
coercion operators.

The concept that floats should implicitly bidirectionally coerce
to/from ints does not exist in other languages.  Particularly
in languages with overloading and implicit constructors/
coercion operators.
--
    --Andrew Koenig
      ark@research.att.com

Andrew Koenig <9577-82971> 059113A (ark@tempel.research.att.com) wrote:
: In article <1994Jan4.203532.2192@datascope.com> sfc@datascope.com (Steve F. Cipolli (P/M)) writes:

: >As the previous writter had stated (para-phase) "No code exists with bool
: >and ++.  It only exists where the soon-to-be keyword "bool" conflicts with
: >a typedef.  Any keyword added to C++ in the recent past (ie. template), could
: >as easily conflicted with existing code typedefs/classes/variables.  So why
: >the special treatment for bool.

: What special treatment?

The special treatment to which I refer is the ++ and the related compatibility
mechanisms.  The point I am trying to make, is that the compatibility is only
necessary to combat code which already uses the new keyword "bool".  I do not
know of any case in which the introduction of a new keyword was hobbled with
a scheme for alleviating existing code of keyword conflicts which would
otherwise occur (namely the ++ and coercion components of the bool proposal).

: >: Because the practice is exceedingly widespread among C and C++ programmers,
: >: the proposal accommodates it temporarily as a transition aid.  The intent is
: >: to remove ++ on bool values in the next version of the standard.

: >I have never seen this happen in practice.

: Neither have I, because neither C nor C++ has gone into the second version
: of its standard.  We won't know whether it's possible to removge things
: from a standard until we try, and that will probably be a decade or so
: from now, but at least we intend to leave open the possibility.

: Or did I misunderstand you?  You seem to be saying that you had never seen
: a feature removed from a subsequent version of a standard, and I agree.
: If instead you were saying you have never seen ++ applied to a Boolean
: value, all I can say is that I have, many times.  The typical usage is

:  bool aflag, bflag, cflag;

:  /* ... */

:   switch(option) {
:   case 'a': aflag++; break;
:   case 'b': bflag++; break;
:   case 'c': cflag++; break;
:   default: complain();
:   }

No, I meant the former.  Though I still wonder about the logic of the latter
since overflow is a dangerous possibility.

: >: Because if the standard breaks too much existing code, vendors will
: >: simply ignore it.

: >I do not think this is true, at least not any more.

: Examples of languages standards that have been ignored for precisely that
: reason include PL/I and Pascal.  Remember, Pascal was the dominant system
: programming langauge on DOS machines for quite a while -- not exactly
: an unpopular language.  But because the Pascal standard did not reflec
: actual usage, vendors ignored it.

I'll accept your explanation here, but I don't think we are talking about
usage of C++, in as much as we are talking about C usage in C++.  The C
community has embraced C++ (for the many pain-staking efforts of the C++ to
maintain compatibility - applause); I don't think that the C community will
find (with or without the bool compatibility) a language which will carry
them into object oriented programming as easily as C++.

-Stephen

jimad@microsoft.com (Jim Adcock) writes:

>As a strawman counterproposal, how about if we bite the bullet, have a
>'real' bool type WITHOUT the implicit coercion back from int to bool,
>and let people fix the code which is currently busted?  Compilers could
>still implement the implicit coercion from int->bool as a deprecated
>backwards compatibility feature -- at the expense of issuing a warning.

That's ok, but I would hope that my compiler offered a option
to disable that warning.  If I have to interface with old code that I
don't have control over (eg. third party libraries, especially C
libraries) which generates lots of these warnings, it would be a real
pain.  There is a lot of C code such as

 #define foo() do { ... } while(0)

in C header files used by C++ programs, and it would be very annoying
if there was no way to disable the warning every time
you use foo() other than by modifying the header file.

I certainly don't want my compiler vendor to tell me that they didn't
provide such an option because the standard _required_ them to emit a
diagnostic for such code.

>A further advantage of this counterproposal is that it would
>continue to allow a reasonable type hierachy:
>
>bool -> char -> short => int => long
>
>verses the current [rather strange] proposal:
>
>bool -> char -> short => int => long
> ^                        |
> |                        |
> +------------------------+

What do the arrows in your diagrams mean?  I think your diagrams are
misleading.  All the following assignments are legal:

 char c; short s; int i; long l;
 ...
 c = s, c = i, c = l;
 s = c, s = i, s = l;
 i = c, i = s, i = l;
 l = c, l = s, l = i;

So a more useful diagram would be

 char -------- short
 |  \      /  |
 |    \     /    |
 |      \ / |
 |      / \ |
 |    /    \ |
 |  /      \ |
 int --------- long

where _all_ the connections are bi-directional.
Under the committees proposal, bool would be bidirectionally connected
to all the other types in this diagram.  Under your proposal,
bool would be the only type for which the connections where one-way.
(Of course, this non-orthogonality does make some sense, because bool
is not really a numeric type and the others are.)

--
Fergus Henderson        |   "People who brook no compromise in programming
                        |   languages should program in lambda calculus or
fjh@munta.cs.mu.OZ.AU   |   machine language, depending." --Andrew Koenig.

(I know I'm going to regret joining the fray on this one, but ...)

In article <9400614.6079@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU (Fergus Henderson) writes:

>  jimad@microsoft.com (Jim Adcock) writes:

>  >As a strawman counterproposal, how about if we bite the bullet, have a
>  >'real' bool type WITHOUT the implicit coercion back from int to bool,
>  >and let people fix the code which is currently busted?  Compilers could
>  >still implement the implicit coercion from int->bool as a deprecated
>  >backwards compatibility feature -- at the expense of issuing a warning.

>  That's ok, but I would hope that my compiler offered a option
>  to disable that warning.  If I have to interface with old code that I
>  don't have control over (eg. third party libraries, especially C
>  libraries) which generates lots of these warnings, it would be a real
>  pain.  There is a lot of C code such as

>          #define foo() do { ... } while(0)

>  in C header files used by C++ programs, and it would be very annoying
>  if there was no way to disable the warning every time
>  you use foo() other than by modifying the header file.

I didn't see the original version of the proposal, but it seems to me
that catching unintended occurences of
    while (a = 0) { ... }
should be one of the major justifications for introducing a Bool type, and
an implicit conversion from int to bool should at least elicit a warning.

With regard to
    #define foo() do { ... } while(0)
it seems reasonable to allow implicit conversions from a *constant*
zero (and perhaps one) to bool, just as 0 can be converted to any pointer
type:
 char *p;
 int i = 0;
 p = 0; // OK
 p = i; // error, or at least warning

With regard to the exchange between Andrew Koenig and others regarding
the question of "special treatment" for new reserved words, there's a
substantive argument that Andrew appears to be missing, perhaps because
it's wrapped in so much extraneous junk.  I'll try one more time to explain
with a concrete example. Code such as this:
 typedef int Boolean;
 #define FALSE 0
 #define TRUE 1

 Boolean verbose;
 ...
 while ((c = getopt(argc,argv,"v"))!=EOF) switch (c) {
     case 'v': verbose++; break;
will not be affected at all.  It may be that the programmer really wants
'verbose' to be an integer so that he can write, e.g.,
 if (verbose) some_debugging_output();
 if (verbose > 1) some_really_obscure_debugging_output();
allowing an invocation such as
 foo -vv bar
In this case, one might reasonably question the choice of the name "Boolean".
It's only if the programmer happened to use the identifier 'bool', that
he has a problem with the proposed change.  He then has two choices:
    - change the name to something else, such as "my_bool"
    - make sure all uses really do conform to "standard" useage of the new
      bool type.
In this way, the situation is no different from programs that happen to use
"try" or "catch" or "template".

Finally, my vote:  I like the idea of a first-class Boolean type
(especially so that I can overload 'operator bool()'), BUT I'd prefer
it not be in the standard.  I agree with Ron Guillemet (sp?):
The standards people should be standardizing the *current* language, not
new features, however worthwhile.  There could be separate "extensions
standards" that suggest a particular form for each proposed new feature
(meaning, for example "If you want to add a boolean type, here's how you
should do it"), or extensions could simply be deferred
to version II of the standard.  The way things are going now, there
may never be a version II, since there may never be a version I :-).
--
Marvin Solomon                  Professor and Chair
Computer Sciences Department    University of Wisconsin
1210 W. Dayton St.              Madison WI, USA
(608) 262-1204                  solomon@cs.wisc.edu

In article <1994Jan5.231950.2910@datascope.com> sfc@datascope.com (Steve F. Cipolli (P/M)) writes:

> The special treatment to which I refer is the ++ and the related compatibility
> mechanisms.  The point I am trying to make, is that the compatibility is only
> necessary to combat code which already uses the new keyword "bool".

Not true.  The compability mechanisms are there to enable code that already
uses the concept of Boolean values to be made to use the new type
with as little change as possible.

> I do not
> know of any case in which the introduction of a new keyword was hobbled with
> a scheme for alleviating existing code of keyword conflicts which would
> otherwise occur (namely the ++ and coercion components of the bool proposal).

I can't think of any other case in which the committee introduced a new
facility with the intent of picking up existing concepts and usage.

> No, I meant the former.  Though I still wonder about the logic of the latter
> since overflow is a dangerous possibility.

But a rare one, especially if ints are 32 bits.  Realistically, no one
specifies an option letter 65536 times, let alone 4294967296 times.

> I'll accept your explanation here, but I don't think we are talking about
> usage of C++, in as much as we are talking about C usage in C++.  The C
> community has embraced C++ (for the many pain-staking efforts of the C++ to
> maintain compatibility - applause); I don't think that the C community will
> find (with or without the bool compatibility) a language which will carry
> them into object oriented programming as easily as C++.

A significant fraction of the C community is not interested in object-oriented
programming.  Indeed, some of them would rather see C++ go away entirely.
For example, the C standards committee has begun work on the next version
of the C standard; it is likely that it will go in quite a
different direction from C++.
--
    --Andrew Koenig
      ark@research.att.com

In <CHzA9s.Crz@biles.com> daniels@biles.com (Brad Daniels) writes:

>In article <KANZE.93Dec9193850@slsvhdt.us-es.sel.de>,
>James Kanze <kanze@us-es.sel.de> wrote:
>...
>>I think that the only reason for supporting x++ is to avoid breaking
>>existing programs.  It is not meant that this be the normal way of
>>setting a bool to true.
>>
>>x-- was not supported because any possible interpretation would result
>>in a silent change in some programs.  For the rare programs which use
>>this idiom, it was felt that it was better to let the compiler give an
>>error rather than perhaps doing the wrong thing.
>>
>>Please understand that the consistency argument has no weight here.
>>From a purely logical point of view, neither operator would be
>>supported.  Pragmatics means trying to avoid breaking existing
>>programs.  Defining x++ to mean x=true helps; there is no plausible
>>definition for x-- which would help.

>I suspect you are right that x++ is supported to avoid breaking existing
>programs, but the logic here eludes me completely.  *No* existing program
>uses a variable of type bool, and therefore, *no* exisiting program uses
>operator++ on a bool variable.  There is absolutely no need to support
>operator++ on bools, at least from the standpoint of backward compatibility.

>If the idea was to define useful semantics for ++, I think the attempt was
>somewhat misguided.  The operator really should be removed from the bool
>type...

>- Brad


Actually, _I_ have programs that use type bool extensively.  By an odd
coincidence, I have a "bool.h" that defines bool, true and false as enums
(for C++ only, #defineds for C), and thus most of my programs will
become illegal with the introduction of this type.  I will be very happy to
(eventually) simply cut out the "#include <bool.h>" and have the code "just
work".  Although the committee explored several systems to see what definitions
of boolean types there (I counted about 9 or 10 different ones in the
various components of a typical UN*X system), it did try to come up with
names which both "fix into the spirit" of the other keywords, and still weren't
used by many programs.

As I used similar criteria for my own library, I will be happy to get rid
of my private type and use a standard type.  I applaud the efforts of Dag
and Andy to ensure my programs _which_ _do_ _use_ _variables_ _of_ _type_
_bool_ (and may indeed (but I doubt it; this isn't my style) use operator++)
do not have any silent changes.

Yes, very few existing programs use type "bool".  But many, many programs
use types with the semantics of "bool".  The (now accepted) proposal allows
a migration period where the other types might (hopefully easily) be replaced
with type bool and the program still works.  The intent (as I understand it)
of this addition to C++ was to first codify existing practice and semantics
of "boolean" types, then choose a name for a type that embodied a formal
set of those semantics, and see what falls out of the new built in type.
(overloading, etc).

Perhaps operator++ should not have been defined.  Probably it should eventually
be disallowed.  Purists might well say the same for built conversions
bool <-> int.  One of the things I enjoy more and more about C++ is the
ability to express my intent within the language.  If I want to code a
generic algorithm, I have templates.  If I have some strange type conversions
or hacked-up bit re-interpretations, I can now use new-style casts.  If  I
want to code two functions that do the same thing sematically on fundamently
different types, I have overloading.  _Now_, if I want to use booleans, I can.
This proposal is the beginning of ensuring consistancy of expression over
the semantics of "boolean-like" objects in diverse programs, and I applaud
that.

-simon tooke

Poster Of Rhetoric.

===============================================================================
Simon Tooke  (not speaking for) SCO Canada, Inc.         Voice:  (416) 922-1937
....!scocan!simon             simon@sco.com                Fax:  (416) 922-2704
130 Bloor St. West. Suite 1001, Toronto, Ontario, Canada  M5S 1N5

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

>In <comp.std.c++> damian@cs.monash.edu.au (Damian Conway) writes:
>>
>>I was suggesting that if there is a built-in operator:
>> bool operator<(bool,bool);
>>Then the other operators taking bool as a 1st arg:
>> template <class notBool>
>> bool operator<(bool,notBool);
>>ought NOT be defined, thereby catching at compile-time the much-lamented:
>> if (a<b<c)
>>  DoSomethingUnexpected();

>I see the problem, and I agree that would be good if we could catch
>that one.  The underlying problem is that C++ has a fairly extensive
>set of automatically applied conversions; of course, what we think is
>a problem in this context also makes the language easier to use in
>other contexts.

What I would like is a new keyword  noconv. which means that
yes I have said how to make a Fred from a Wilma but DONT unless I ask you
to..
eg
typedef noconv int Fred;
typedef noconv int Wilma;
Fred F = (Fred) 2;;
Wilma W = (Wilma) 3;
F=W;   // Not legal as freds are longer automatically also wilmas.

// Bool could now just be declared if you want it.

typedef noconv int Bool;


What the no conv means to the compiler is that it can generate code and
treat Fred and Wilma as ints but they are not ints and I want to be
told if I make a mistake and use one as something else.
Likewise the typo in main will compile but is clearly silly.

class Buffer {
 char *Ptr;
 int size;
 Buffer(int S);
 };

int  InputData( Buffer &B);
int PrintData(Buffer &B);

main()
{
  int B=3;
  Buffer BB(50);

 InputData(B);
 PrintData(B);

}

There is currently no distinction between a constructor and a type converter

declaring
noconv Buffer(int S);
meaning that this was not to be used for automatic type promotions would
remove this problem.

typing
PrintData(Buffer(3)); would still then be legal even if it was unlikely to
be useful.

Note I do not believe I have thought this through enough to be seriously
suggesting the idea but the comment seemed appropriate at this point in the
discussion. So if you shoot my idea down in flames dont be suprised if
I start arguing on your side.

Alan

>    -- Dag
--
                           |  This space was intentionally left blank,
                           |  until some silly included a self descriptive
                           |  self referential self referential self ...
                           | ... Stack overflow. Executing cleanup rm *.*

In article <2dvt4e$nme@nic.lth.se> dag@control.lth.se (Dag Bruck) writes:
>In <comp.std.c++> kjhopps@mmm.com writes:
>>I have seen postings recently related to a new type, bool.  I am wondering
>>about some particular aspects of its behavior.  In particular:

>>    3) Can I use a bool as a bit field, i.e. (bool x:1)?

>Yes, you can, but arrays cannot be bit-packed (because a bool must
>be an adressable unit, i.e., sizeof(bool) >= 1).

I thought bool was a signed integral type, doesn't that mean that bool x:1
should have the values 0 and -1, which aren't legal for bool, or is this a
special case?? Is it really legal??

ark@alice.att.com (Andrew Koenig) writes:

>Relational operators on Booleans are actually sometimes useful.

">=" even LOOKS a bit like an Implication operator.  "<=" looks
even more like "is implied by" :)

--
Warwick

In article <9334414.20749@mulga.cs.mu.oz.au>,
Fergus Henderson <fjh@munta.cs.mu.OZ.AU> wrote:
...
>b++ was defined because there are existing programs that do
> bool b;
> ...
> b++;
>but it is immediately depreciated.
>
>Sure, the committee could also introduce b-- for symmetry and then
>immediately depreciate it too, but they might as well introduce it
>and then immediate abolish it, since it's not important for backwards
>compatibility.
...
>Of course not.  But existing programs _do_ increment variables of type
>"bool", "boolean", "Bool", etc., and so it's necessary to allow incrementing
>of bools to allow easy conversion of these programs.

I am mightily perplexed at these assertions.  If bool was not part of the
language until a month ago, how could there be existing programs with
bool variables?  Did some compiler implement it as an extension?  If so,
did every compiler which implemented it as an extension implement it the
same way?  Really, it seems completely pointless to support such behavior,
even if the support is immediately deprecated.

- Brad
--------------------------------------------------------------------------
+ Brad Daniels                  | Until you can prove unequivocally that +
+ Biles and Associates          | you're arguing epistemology with me,   +
+ These are my views, not B&A's | I won't argue epistemology with you.   +
--------------------------------------------------------------------------

In article <KANZE.93Dec9193850@slsvhdt.us-es.sel.de>,
James Kanze <kanze@us-es.sel.de> wrote:
...
>I think that the only reason for supporting x++ is to avoid breaking
>existing programs.  It is not meant that this be the normal way of
>setting a bool to true.
>
>x-- was not supported because any possible interpretation would result
>in a silent change in some programs.  For the rare programs which use
>this idiom, it was felt that it was better to let the compiler give an
>error rather than perhaps doing the wrong thing.
>
>Please understand that the consistency argument has no weight here.
>From a purely logical point of view, neither operator would be
>supported.  Pragmatics means trying to avoid breaking existing
>programs.  Defining x++ to mean x=true helps; there is no plausible
>definition for x-- which would help.

I suspect you are right that x++ is supported to avoid breaking existing
programs, but the logic here eludes me completely.  *No* existing program
uses a variable of type bool, and therefore, *no* exisiting program uses
operator++ on a bool variable.  There is absolutely no need to support
operator++ on bools, at least from the standpoint of backward compatibility.

If the idea was to define useful semantics for ++, I think the attempt was
somewhat misguided.  The operator really should be removed from the bool
type...

- Brad
--------------------------------------------------------------------------
+ Brad Daniels                  | Until you can prove unequivocally that +
+ Biles and Associates          | you're arguing epistemology with me,   +
+ These are my views, not B&A's | I won't argue epistemology with you.   +
--------------------------------------------------------------------------

In article <CHzA9s.Crz@biles.com> daniels@biles.com (Brad Daniels) writes:
>programs, but the logic here eludes me completely.  *No* existing program
>uses a variable of type bool, and therefore, *no* exisiting program uses
>operator++ on a bool variable.  There is absolutely no need to support
>operator++ on bools, at least from the standpoint of backward compatibility.
>
>If the idea was to define useful semantics for ++, I think the attempt was
>somewhat misguided.  The operator really should be removed from the bool
>type...
>


I think the point being made is that current *libraries* can change over
to the new bool type simply by replacing their old
   typedef int BOOL;
   #define FALSE 0
   #define TRUE  1

declarations with
   typedef bool BOOL;
   #define FALSE false
   #define TRUE  true

without worrying too much about code using the library being broken. Without
this guarantee, there would be more resistance to making the change and users
of the libraries would have to live with both a standard and a nonstandard
boolean type.

Note, since x++ is defined as being depreciative, and all C++
implementations are quality implementations ( :-] ), then your compiler
should give you the option of warning for this code which will eventually
break in future implementations of the compiler. It's a compromise. Life's
full of them.

>- Brad
>--------------------------------------------------------------------------
>+ Brad Daniels                  | Until you can prove unequivocally that +
>+ Biles and Associates          | you're arguing epistemology with me,   +
>+ These are my views, not B&A's | I won't argue epistemology with you.   +
>--------------------------------------------------------------------------

Take care
    Robert
--
/----------------------------------+------------------------------------------\
| Robert N. Deviasse               |"If we have to re-invent the wheel,       |
| EMAIL: g2devi@cdf.utoronto.ca    |  can we at least make it round this time"|
+----------------------------------+------------------------------------------/

In article <CHzA9s.Crz@biles.com>, Brad Daniels <daniels@biles.com> wrote:
>
>I suspect you are right that x++ is supported to avoid breaking existing
>programs, but the logic here eludes me completely.  *No* existing program
>uses a variable of type bool, and therefore, *no* exisiting program uses
>operator++ on a bool variable.

 This is a rather broad and, I suspect, false assertion. It is
certainly true that no existing program uses the newly defined ISO C++
type 'bool'. It does not follow, however, that there are no programs that
use a type named 'bool' for two-state logic. There are, for example, lots of
programs that use BOOL. It's not much of a stretch to imagine a programmer
who thinks that capitalized type names are disgusting, and uses all lower case
instead.
 But more important is the idea that there ought to be an easy
transition to the new type. So the underlying notion is that whatever you've
been using for booleans in the past, you ought to be able to replace them with
'bool' and have a reasonably good chance that your program will continue to
work as well as it did before.
 -- Pete

In article <CHzA9s.Crz@biles.com> daniels@biles.com (Brad Daniels) writes:

> I suspect you are right that x++ is supported to avoid breaking existing
> programs, but the logic here eludes me completely.  *No* existing program
> uses a variable of type bool, and therefore, *no* exisiting program uses
> operator++ on a bool variable.  There is absolutely no need to support
> operator++ on bools, at least from the standpoint of backward compatibility.

That's simply not true.  There are plenty of programs that do things like:

 typedef int bool;

 bool aflag, bflag, cflag, dflag;

 // ...

  switch (optchar) {
  case 'a':
   ++aflag;
   break;
  case 'b':
   ++bflag;
   break;
  case 'c':
   ++cflag;
   break;
  casd 'e':
   ++dflag;
   break;
  // ...
  }

The point is to be able to remove the `typedef int bool;' declaration
and have this program still work.
--
    --Andrew Koenig
      ark@research.att.com

jak@cs.brown.edu (Jak Kirman) writes:

> [re:   bool x; ... ; x++]

>I find the notion that incrementing a boolean makes it "more true" and
>decrementing it makes it "more false" quite intuitive, but of course
>this is just my opinion.


If:
 x--;

is same as:

 x=false;

What would you expect of:

 x-=1;

?

 x-=true;

?



To me:

 x-=1;

means

 x=bool(x ? 0 : -1);

ie.
 x=x ? bool(0) : bool(-1);

ie.
 x=x ? false : true;

ie.
 x=!x;

--
Warwick

daniels@biles.com (Brad Daniels) writes:

|"I am mightily perplexed at these assertions.  If bool was not part of the
|"language until a month ago, how could there be existing programs with
|"bool variables?  Did some compiler implement it as an extension?  If so,
|"did every compiler which implemented it as an extension implement it the
|"same way?  Really, it seems completely pointless to support such behavior,
|"even if the support is immediately deprecated.

Well, the way I interpret all these postings and the `bool' proposal is that
old programs, because of the redefinition of some operators like !=, == and
the like will now be implicitly using boolean variables.
--
 -----------------------------------------------------------------------------
| My current address (rvloon@cv.ruu.nl) will no longer be valid after         |
| January 1st, 1994. Please send new mail to rvloon@motif.hacktic.nl instead. |
| Note that this is a UUCP connection, which means that answering messages    |
| may take longer than before.                                                |
 -----------------------------------------------------------------------------

Ronald van Loon       | E-mail: rvloon@motif.hacktic.nl <-- note NEW address!
Maintainer of Motif++ | S-mail: St. Janskerkhof 18, 3811 HW  AMERSFOORT
                      |         The Netherlands.
Job offers welcome.   | Phone : +31 33 758 293. (FAX: available on request)

In article <16775@uqcspe.cs.uq.oz.au>, warwick@cs.uq.oz.au (Warwick Allison) writes:
> ark@alice.att.com (Andrew Koenig) writes:

> >Relational operators on Booleans are actually sometimes useful.

> ">=" even LOOKS a bit like an Implication operator.  "<=" looks
> even more like "is implied by" :)

Let's not go down this road, please?  Pascal tried it, and it turned out
to be a wonderfully dead end.
--
 (This man's opinions are his own.)
 From mole-end    Mark Terribile

 mat@mole-end.matawan.nj.us, Somewhere in Matawan, NJ

In article <1993Dec14.133507.12596@cdf.toronto.edu> g2devi@cdf.toronto.edu (Robert N. Deviasse) writes:

-> I think the point being made is that current *libraries* can change over
-> to the new bool type simply by replacing their old
->    typedef int BOOL;
->    #define FALSE 0
->    #define TRUE  1

-> declarations with
->    typedef bool BOOL;
->    #define FALSE false
->    #define TRUE  true

-> without worrying too much about code using the library being broken. Without
-> this guarantee, there would be more resistance to making the change and users
-> of the libraries would have to live with both a standard and a nonstandard
-> boolean type.

Exactly.

-> Note, since x++ is defined as being depreciative, and all C++
-> implementations are quality implementations ( :-] ), then your compiler
-> should give you the option of warning for this code which will eventually
-> break in future implementations of the compiler. It's a compromise. Life's
-> full of them.

Yes indeed.

People who brook no compromise in programming languages
should program in lambda calculus or machine language, depending.
--
    --Andrew Koenig
      ark@research.att.com

In article <27374@alice.att.com>, ark@alice.att.com (Andrew Koenig) writes:
> In article <CHzA9s.Crz@biles.com> daniels@biles.com (Brad Daniels) writes:
>
> > I suspect you are right that x++ is supported to avoid breaking existing
> > programs, but the logic here eludes me completely.  *No* existing program
> > uses a variable of type bool, and therefore, *no* exisiting program uses
> > operator++ on a bool variable.  There is absolutely no need to support
> > operator++ on bools, at least from the standpoint of backward compatibility.
>
> That's simply not true.  There are plenty of programs that do things like:
>
>  typedef int bool;
>
>  bool aflag, bflag, cflag, dflag;
>
>  // ...
>
>   switch (optchar) {
>   case 'a':
>    ++aflag;
>    break;
...

>   casd 'e':
>    ++dflag;
>    break;
>   // ...
>   }
>
> The point is to be able to remove the `typedef int bool;' declaration
> and have this program still work.
> --
>     --Andrew Koenig
>       ark@research.att.com

IMHO, programs like this deserve to be broken! If someone uses booleans he should use them right.

There are 2 simple ways for making this program work again:

- Make a global replace of 'bool' to some other name like 'OptionFlags'
  and everything works as before.

- Do it right and change the places with ++flag to flag = true; I can't
  imagine that this would be a task that takes a big effort...

Just my 2 cent...
Hartmut
--
+==============================|==============================+
| 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 <1993Dec15.092048.13770@us-es.sel.de> kocher@us-es.sel.de (Hartmut Kocher) writes:

> IMHO, programs like this deserve to be broken!

It doesn't metter --
the standards committee does not have the right to break them.
--
    --Andrew Koenig
      ark@research.att.com

In <comp.std.c++> trickr@uh2372p03.daytonoh.ncr.com (Ralph Trickey) writes:
>I thought bool was a signed integral type, doesn't that mean that bool x:1
>should have the values 0 and -1, which aren't legal for bool, or is this a
>special case?? Is it really legal??

I don't think we have to be concerned with the representation or what
it means if bool had been an integer.  The general rules say that:

 - the values of a bool are false and true;

 - false promoted to int yields 0, true yields 1.

So, even a one-bit bool is either false or true, and promotes to 0 or 1.

     -- Dag

        In article <27387@alice.att.com>, ark@alice.UUCP (Andrew Koenig) wrote:
>In article <1993Dec15.092048.13770@us-es.sel.de> kocher@us-es.sel.de (Hartmut
Kocher) writes:
>
>> IMHO, programs like this deserve to be broken!
>
>It doesn't metter --
>the standards committee does not have the right to break them.

        But they have the right to break "typedef int bool;"...?

--
+-------+ "Congress shall make no law respecting an establishment of religion,
|John   | or prohibiting the free exercise thereof; or abridging the freedom of
|Davison| speech, or of the press; or the right of the people peaceably to as-
+-------+ semble, and to petition the government for a redress of grievances."

In article <2e6js2$8cm@nic.lth.se> dag@control.lth.se (Dag Bruck) writes:
>In <comp.std.c++> barmar@think.com (Barry Margolin) writes:
>>
>>The intent is clearly to make bool's act similarly to ints that are being
>>interpreted in boolean contexts.
>
>I find it very rewarding when people interpret not only the technical
>description but also the intent, and it's correct!
>
>    -- Dag

If it was indeed the intent of the C++ standardization committee to have
this new (and different) type act very much like int, then one might well
ask why int was not considered good enough in the first place.

If, on the other hand, the committee really *did* want a new and distinct
type (I assume as a way of enhancing ``type-safety'') then one must wonder
why this goal was not actually persued to its logical conclusion.

All in all, it seems we now have the worst of both worlds... yet more
keyword pollution with no real additional type-safety.

--

-- Ronald F. Guilmette, Sunnyvale, California -------------------------------
------ domain address: rfg@netcom.com ---------------------------------------
------ uucp address: ...!uunet!netcom.com!rfg -------------------------------

In <comp.std.c++> rfg@netcom.com (Ronald F. Guilmette) writes:
>
>If it was indeed the intent of the C++ standardization committee to have
>this new (and different) type act very much like int, then one might well
>ask why int was not considered good enough in the first place.

Because we wanted overloading on bool.  A great number of people
distinguish between booleans and integers, and want to express that in
their C++ code.

>If, on the other hand, the committee really *did* want a new and distinct
>type (I assume as a way of enhancing ``type-safety'') then one must wonder
>why this goal was not actually persued to its logical conclusion.

Because we want to make the transition, i.e., porting existing code to
the new rules, as easy as possible.

(As a side note: my experience is that persuing something to its
logical conclusion does not work well when there are conflicting
interests, which the net discussion has shown.)

>All in all, it seems we now have the worst of both worlds... yet more
>keyword pollution with no real additional type-safety.

On the contrary; we have reduced the pollution by standardizing on one
name for Boolean.  The current situation where different libraries

 - use different names for the Boolean type
 - the same name with incompatible definitions
 - definitions of Boolean that do not work well
   in C++ (e.g., enumeration)

is a significant practical problem that I think we have solved in the
long run.

Sorry for repeating myself.

     -- Dag

In article <2eq1tk$as3@crchh7ab.bnr.ca> davisonj@ecn.purdue.edu (John Davison) writes:

>         But they have the right to break "typedef int bool;"...?

Yes, but just barely.  The point is that such breakages are glaringly
obvious and there is a simple fix: systematically replace all instances
of `bool' by something unique, as in

 CC -Dbool=cbqwuygerb0813y540poawwf7283f7gwjqhe file.c
--
    --Andrew Koenig
      ark@research.att.com

In article <27412@alice.att.com> ark@alice.UUCP () writes:
>In article <2eq1tk$as3@crchh7ab.bnr.ca> davisonj@ecn.purdue.edu (John Davison) writes:
>>    But they have the right to break "typedef int bool;"...?
>Yes, but just barely. The point is that such breakages are glaringly
>obvious and there is a simple fix: systematically replace all instances
>of `bool' by something unique, as in
>
> CC -Dbool=cbqwuygerb0813y540poawwf7283f7gwjqhe file.c

    Isn't this likely to cause some problems when bool is used in system
header files?
    Jon
    __@/

warwick@cs.uq.oz.au (Warwick Allison) writes:

>ark@alice.att.com (Andrew Koenig) writes:

>>Relational operators on Booleans are actually sometimes useful.

>">=" even LOOKS a bit like an Implication operator.  "<=" looks
>even more like "is implied by" :)

Great. That is precisely one reason why they should be forbidden.
They have just the opposite semantics to that their look implies.

>= means is implied by, <= means implies.
--
 David Kastrup        dak@pool.informatik.rwth-aachen.de
 Tel: +49-241-72419 Fax: +49-241-79502
 Goethestr. 20, D-52064 Aachen

damian@cs.monash.edu.au (Damian Conway) writes:

>I take it comparison operators (< > <= >=) will work by conversion to int?
>
>Might have been nice to invalidate these ops for a bool first argument, thereby
>nipping in the bud the odious:
>
> if ( 1 < x < 10 ) {...
>
>construct.
>
>Yeah, I know it would break existing code, but such code probably deserves to be
>broken :-)

Good quality compilers already warn about these constructs.
E.g. with GNU C, I get the following:

 t.c:2: warning: comparisons like X<=Y<=Z do not have their
                 mathematical meaning

(Note that GNU C++ is not as good as GNU C in this (and other) respects.)

Now that C++ has a bool type, it will be very easy for compilers to
issue a warning in these cases.  I think that leaving this as a
quality-of-implementation issue is not so bad.  If your compiler
doesn't warn about such constructs, then lobby your vendor.

--
Fergus Henderson                     fjh@munta.cs.mu.OZ.AU

Is this the same as

 bool(e1) != bool(e2)
?
--
        John M Kewley

ICL Computers Limited, Wenlock Way, West Gorton, Manchester. M12 5DR
Tel: (+44) 61 223 1301 X2138  Email: jk@fiveg.icl.co.uk or jk@cs.man.ac.uk

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

>In <comp.std.c++> kjhopps@mmm.com writes:
>>...
>>    4) Are increment/decrement operators permitted with bool?

>Increment yes, decrement no. b++ always means b=true (as far as we
>could tell).  It is unclear what b-- means, and it does not seem to be
>common.

This seems quite inconsistent.  If b++ means b=true, to have b-- NOT mean
b=false seems surprising.  But even if b-- were defined to work consistently
with b++, IMHO those definitions are wrong.  I think both b++ and b-- should
TOGGLE the value of b.

I submit that the effects of all operators on type bool need to be defined.
Further, I submit that the proper definition should follow the principle
of least surprise -- that the operators should do what most people find
natural and intuitive.  Determining this may be difficult, but it is the
best solution.

I would be VERY interested in hearing what the C++ community thinks about
the following (and I hope the committee is even more interested).
Consider the following code fragment and then give your opinions.

    extern bool x;
    extern int i;
    x = i;  // Legal?  What does it do?
    x = (bool)i; // Is this different from x=i?
    i = x;  // Has i changed from before?
    extern void* p;
    x = p;  // Legal?  What does it do?
    x = (bool)p; // Legal?  Different from x=p?
    extern double d;
    x = d;  // Legal?  What does it do?
    x = (bool)d; // Legal?  Different from x=p?
    extern bool y, z;
    x = y + z;  // Legal?  What does it do?
    x = y - z;  // Legal?  What does it do?
    x = y * z;  // Legal?  What does it do?
    x = y / z;  // Legal?  What does it do?
    x = y % z;  // Legal?  What does it do?
    x = y | z;  // Legal?  What does it do?
    x = y & z;  // Legal?  What does it do?
    x = y ^ z;  // Legal?  What does it do?
    x++;  // Legal?  What does it do?
    x--;  // Legal?  What does it do?
    x += i;  // Legal?  What does it do?
    x -= i;  // Legal?  What does it do?
    x *= i;  // Legal?  What does it do?
    x /= i;  // Legal?  What does it do?
    x %= i;  // Legal?  What does it do?
    x &= i;  // Legal?  What does it do?
    x |= i;  // Legal?  What does it do?
    x ^= i;  // Legal?  What does it do?

Finally, as the first respondent, here are my opinions.  I find it
very useful to think of a bool as a 1-bit unsigned, with all the integer
operations behaving accordingly, except for assignment, where ALL nonzero
values become 1 when stored in a bool.

    extern bool x;
    extern int i;
    x = i;  // Legal?  What does it do?
    x = (bool)i; // Is this different from x=i?
Both legal and equivalent to x=i?true:false;

    i = x;  // Has i changed from before?
The value of i is always 0 or 1 now.

    extern void* p;
    x = p;  // Legal?  What does it do?
    x = (bool)p; // Legal?  Different from x=p?
Both legal and equivalent to x=p?true:false;

    extern double d;
    x = d;  // Legal?  What does it do?
    x = (bool)d; // Legal?  Different from x=p?
Both legal and equivalent to x=d?true:false;

    extern bool y, z;
    x = y + z;  // Legal?  What does it do?
Legal and equivalent to x = y|z.

    x = y - z;  // Legal?  What does it do?
Legal.  Some possible interpretations (I think I like #1 best)
 1) x = (bool)((int)y - (int)z); { same as y^z }
 2) x = y?!z:false; { x=true if and only if y=true and z=false }

    x = y * z;  // Legal?  What does it do?
Legal and equivalent to x=y&z;

    x = y / z;  // Legal?  What does it do?
Illegal.

    x = y % z;  // Legal?  What does it do?
Illegal.

    x = y | z;  // Legal?  What does it do?
Legal and equivalent to x = ((int)y | (int)z) ? true : false;

    x = y & z;  // Legal?  What does it do?
Legal and equivalent to x = ((int)y & (int)z) ? true : false;

    x = y ^ z;  // Legal?  What does it do?
Legal and equivalent to x = ((int)y ^ (int)z) ? true : false;

    x++;  // Legal?  What does it do?
Legal and equivalent to x = !x;

    x--;  // Legal?  What does it do?
Legal and equivalent to x = !x;

    x += expr;  // Legal?  What does it do?
    x -= expr;  // Legal?  What does it do?
    x *= expr;  // Legal?  What does it do?
    x /= expr;  // Legal?  What does it do?
    x %= expr;  // Legal?  What does it do?
    x &= expr;  // Legal?  What does it do?
    x |= expr;  // Legal?  What does it do?
    x ^= expr;  // Legal?  What does it do?
All the assignment operators except %= and /= are legal, and behave as
the binary operators above with the expr first converted to a true or false
value.
--
Kevin J. Hopps   e-mail: kjhopps@mmm.com
3M Company   phone: (612) 737-3300
3M Center, Bldg. 235-3B-16 fax: (612) 737-2700
St. Paul, MN 55144-1000

>>>>> "Kevin" == Kevin J Hopps <hopps@yellow.mmm.com> writes:
In article <hopps.755363869@mmm.com> hopps@yellow.mmm.com (Kevin J Hopps) writes:

 Kevin> This seems quite inconsistent.  If b++ means b=true, to have b--
 Kevin> NOT mean b=false seems surprising.  But even if b-- were defined
 Kevin> to work consistently with b++, IMHO those definitions are wrong.
 Kevin> I think both b++ and b-- should TOGGLE the value of b.

It is not clear to me that this would be less confusing; consider the
common idiom

int opt_f = 0;
for (int i = 1; i < argc; i++)
  if (strcmp (argv[i], "-f") == 0)
    opt_f++;

If booleans toggled their value on increment, the above rewritten with
booleans would function differently, something many programmers might
find surprising.  The fact that the above arguably ought to be written
with opt_f=1 instead of opt_f++ is somewhat irrelevant given the
pervasiveness of the increment in this and similar contexts.

I find the notion that incrementing a boolean makes it "more true" and
decrementing it makes it "more false" quite intuitive, but of course
this is just my opinion.

                         Jak Kirman                        jak@cs.brown.edu
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
...there is ample precedent for naming laws and theorems for persons
other than their discoverers, else half of analysis would be named for
Euler.
                           -- ? quoted by W.Dunham in Journey through Genius

In article <rfgCHp8AD.6y5@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:
>In article <2dvt4e$nme@nic.lth.se> dag@control.lth.se (Dag Bruck) writes:
>>Increment yes, decrement no. b++ always means b=true (as far as we
>>could tell).
>That is very interesting.  What if b was *already* true before you incremented
>it??
>>It is unclear what b-- means...
>
>This is a most remarkable assertion.  You have defined the result of b++ to
>always be true.  Why then does it NOT make sense for b-- to be defined to
>always yield false?

The intent is clearly to make bool's act similarly to ints that are being
interpreted in boolean contexts.

Thus, when you increment a non-zero int, it stays non-zero, and hence true
(unless it overflows, in which case the result is undefined).  Code that
uses ++ to "turn on" flags is quite common, although I don't know why (it's
the same number of characters as "=1").

By the same analogy, though, -- when used on an int doesn't necessarily
make it false.  If the flag was turned on with ++ multiple times, you would
need to turn it off with -- an equal number of times to really turn it off
(for this reason, every time I see ++ being used on such variables, I look
around to see whether it's some kind of semaphore).
--
Barry Margolin
System Manager, Thinking Machines Corp.

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

In <comp.std.c++> barmar@think.com (Barry Margolin) writes:
>
>The intent is clearly to make bool's act similarly to ints that are being
>interpreted in boolean contexts.

I find it very rewarding when people interpret not only the technical
description but also the intent, and it's correct!

    -- Dag

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

 [ much quotation discussing new boolean type deleted ]

> ...    Code that
>uses ++ to "turn on" flags is quite common, although I don't know why (it's
>the same number of characters as "=1").

I think it is because programmers of old knew that ++, implemented on
machines with an INCrement instruction, takes less code space than =1.
Of course it will in many cases also run *slower*, but for uses such
as the classic command line flag parsing loop, where you see code of
the form:

static int fflag;
...
 switch (*ap++) {
 ...
 case 'f':
  ++fflag;
  break;
 ...

speed clearly doesn't matter.  (In some rare cases, the number of
times a flag occured *was* significant, i.e. it wasn't really a
boolean.)  The code size advantage certainly applies on the PDP-11 - 6
bytes to set a static to 1, 4 bytes to increment it - and later also
the VAX - 6 bytes versus 5.  It was also pretty certain that the flag
was not going to wrap all the way round back to 0 - it being
impossible to have that many (64K on PDP11, 4G on VAX) instances of
'f' in a single argument list.  Therefore, it became a standard idiom,
no doubt also used in a lot of C++ code.  A pity (in my view), but at
least on the PDP-11 there was some justification.


Mark Taunton.

In article <2e6v9m$9mp@acorn.acorn.co.uk>,
Mark Taunton <mark@acorn.co.uk> wrote:
> In article <2e5rraINNmpp@early-bird.think.com> barmar@think.com (Barry
> Margolin) writes:
>
>  [ much quotation discussing new boolean type deleted ]
>
> > ...    Code that
> >uses ++ to "turn on" flags is quite common, although I don't know why (it's
> >the same number of characters as "=1").
>
> I think it is because programmers of old knew that ++, implemented on
> machines with an INCrement instruction, takes less code space than =1.
> Of course it will in many cases also run *slower*, but for uses such
> as the classic command line flag parsing loop, where you see code of
> the form:
>
> static int fflag;
> ...
>  switch (*ap++) {
>  ...
>  case 'f':
>   ++fflag;
>   break;
>  ...
>
> speed clearly doesn't matter.  (In some rare cases, the number of
> times a flag occured *was* significant, i.e. it wasn't really a
> boolean.)  The code size advantage certainly applies on the PDP-11 - 6
> bytes to set a static to 1, 4 bytes to increment it - and later also
> the VAX - 6 bytes versus 5.  It was also pretty certain that the flag
> was not going to wrap all the way round back to 0 - it being
> impossible to have that many (64K on PDP11, 4G on VAX) instances of
> 'f' in a single argument list.  Therefore, it became a standard idiom,
> no doubt also used in a lot of C++ code.  A pity (in my view), but at
> least on the PDP-11 there was some justification.
>
>
> Mark Taunton.

I beg to disagree as regard the speed. The '++' as well as '--' operators
usually translate ( if that's the correct word to use ) to a single
machine level operation (usually equivalent to one op-cycle) and hence
both tend to be more efficient than normal assignments.



----------------------------------------------------------------------------
Fujitsu Fulcrum Telecommunications Ltd.,            djamel@fulcrum.co.uk
149 Fordrough Lane,
Birmingham,
B9 5FL
----------------------------------------------------------------------------
        Don't knock standards. They are a good thing for employment.

In article <hopps.755363869@mmm.com> kjhopps@mmm.com writes:
>
>I submit that the effects of all operators on type bool need to be defined.
>Further, I submit that the proper definition should follow the principle
>of least surprise -- that the operators should do what most people find
>natural and intuitive.  Determining this may be difficult, but it is the
>best solution.
>
>I would be VERY interested in hearing what the C++ community thinks about
>the following (and I hope the committee is even more interested).
>Consider the following code fragment and then give your opinions.
>

Ok...here are my opinions

>    extern bool x;
>    extern int i;
>    x = i;  // Legal?  What does it do?
 // x=(i==0)?false:true;
>    x = (bool)i; // Is this different from x=i?
 // should evaluate the same as x=i;
>    i = x;  // Has i changed from before?
 // i=(x==true)?1:0;
>    extern void* p;
>    x = p;  // Legal?  What does it do?
 // x=(p==0)?false:true;
>    x = (bool)p; // Legal?  Different from x=p?
 // should evaluate the same as x=p;
>    extern double d;
>    x = d;  // Legal?  What does it do?
 // x=(d==0.0)?false:true;
>    x = (bool)d; // Legal?  Different from x=p?
 // should evaluate the same as x=d;

I agree with you that the boolean types should not be converted to int for
the same reason that doubles/floats are not converted to int and the integer
operator applied.  Further, it seems to me that some operations should not be
allowed.  This is consistent with the current language definition.  For example
float % float is illegal.

>    extern bool y, z;
>    x = y + z;  // Legal?  What does it do?
>    x = y - z;  // Legal?  What does it do?
>    x = y * z;  // Legal?  What does it do?
>    x = y / z;  // Legal?  What does it do?
>    x = y % z;  // Legal?  What does it do?

I think that all of these should be illegal.  Although I can think of some
reasonable results from some these expressions, they can all be done with
another operator.

>    x = y | z;  // Legal?  What does it do?
>    x = y & z;  // Legal?  What does it do?
>    x = y ^ z;  // Legal?  What does it do?

I think that these operations should be legal and have the same value as their
logical counterparts.  In fact, I believe that in this case, treating y and z
as integers (with possible values of 0 and 1 for false and true respectively)
will give appropriate (as in not surprising) results.

>    x++;  // Legal?  What does it do?
 // x = true;
>    x--;  // Legal?  What does it do?
 // x = false;

I think that if x++ is supported, x-- should be for consistency.

>    x += i;  // Legal?  What does it do?
>    x -= i;  // Legal?  What does it do?
>    x *= i;  // Legal?  What does it do?
>    x /= i;  // Legal?  What does it do?
>    x %= i;  // Legal?  What does it do?

I think that these operations should be illegal for the same reason that the
x = x OP i expressions should be illegal (where OP is +, -, *, /, or %).

>    x &= i;  // Legal?  What does it do?
>    x |= i;  // Legal?  What does it do?
>    x ^= i;  // Legal?  What does it do?

These operations have the same effect as x = x OP i (where OP is &, |, or ^).
Furthermore, you left out:
     x &= y;
     x |= y;
     x ^= y;
which should also follow the above criteria.

>
>Finally, as the first respondent, here are my opinions.  I find it
>very useful to think of a bool as a 1-bit unsigned, with all the integer
>operations behaving accordingly, except for assignment, where ALL nonzero
>values become 1 when stored in a bool.
>
 [ some of Kevin's opinions deleted ]
>
>    x++;  // Legal?  What does it do?
>Legal and equivalent to x = !x;
>
>    x--;  // Legal?  What does it do?
>Legal and equivalent to x = !x;
>

While at least you are consistent, I would have to consider existing code.
Alot of the code that I have seen uses an integer type initialized to 0.  If
some condition occurs, the integer type can be incremented, thus making its
value true.  Many times, the integer could get incremented in any number of
places.  Since the increment would take place at least 256 times to distort
the "trueness" of the boolean, programmers continue to increment it, knowing
that the value of the integer will evaluate to true if the value is 1 or 101.
Having x++ toggle the boolean would break this code.  This is why I have x++
meaning x = true.  For consistency sake, x-- means x = false.

 [ more of Kevin's opinions deleted ]
>--
>Kevin J. Hopps   e-mail: kjhopps@mmm.com
>3M Company   phone: (612) 737-3300
>3M Center, Bldg. 235-3B-16 fax: (612) 737-2700
>St. Paul, MN 55144-1000

Stephen Gevers
sg3235@shelob.sbc.com

jak@cs.brown.edu (Jak Kirman) writes:

>[...]

>It is not clear to me that this would be less confusing; consider the
>common idiom

>int opt_f = 0;
>for (int i = 1; i < argc; i++)
>  if (strcmp (argv[i], "-f") == 0)
>    opt_f++;

Common idiom??  Why would anyone want to write code that way?  It's less
readable than "opt_f=1" and requires just as many keystrokes.  And in a
different context it could become a bug: Do opt_f++ INT_MAX+1 times and
opt_f becomes false.

Why not just forbid -- and ++ with bools?  It won't break any existing code,
because no existing code uses bool.

Anders Munch  |  Department of Computer Science
juul@diku.dk  |  University of Copenhagen, Denmark
Still confused but at a higher level

In article <2450@swuts.sbc.com> sg3235@sw1sta.sbc.com (Stephen Gevers)
writes:

|> In article <hopps.755363869@mmm.com> kjhopps@mmm.com writes:

|> >I submit that the effects of all operators on type bool need to be defined.
|> >Further, I submit that the proper definition should follow the principle
|> >of least surprise -- that the operators should do what most people find
|> >natural and intuitive.  Determining this may be difficult, but it is the
|> >best solution.
|> >
|> >I would be VERY interested in hearing what the C++ community thinks about
|> >the following (and I hope the committee is even more interested).
|> >Consider the following code fragment and then give your opinions.
|> >

|> Ok...here are my opinions

    [...]

|> >    x++;  // Legal?  What does it do?
|>  // x = true;
|> >    x--;  // Legal?  What does it do?
|>  // x = false;

|> I think that if x++ is supported, x-- should be for consistency.

I think that the only reason for supporting x++ is to avoid breaking
existing programs.  It is not meant that this be the normal way of
setting a bool to true.

x-- was not supported because any possible interpretation would result
in a silent change in some programs.  For the rare programs which use
this idiom, it was felt that it was better to let the compiler give an
error rather than perhaps doing the wrong thing.

Please understand that the consistency argument has no weight here.

rfg@netcom.com (Ronald F. Guilmette) writes:

>dag@control.lth.se (Dag Bruck) writes:
>>In <comp.std.c++> kjhopps@mmm.com writes:
>>>I have seen postings recently related to a new type, bool.  I am wondering
>>>about some particular aspects of its behavior.  In particular:
>>>    1) what happens when an int with value other than 0 or 1 is assigned
>>>       to a bool?
>>>    2) What happens when various types are cast to a bool?  Do all nonzero
>>>       values become the single representation for "true"?  Perhaps this
>>>       answers question 1.
>>
>>Yes, it does.  Non-zero becomes true.
>
>What types EXACTLY may be cast to type bool?  Integral types?  Floating-
>point types?  Pointer types?  Enumeration types?  Struct/union/class types?
>Reference types?  Pointer to member types?

I would presume that anything that can be cast to int can be cast to bool.

>>>    4) Are increment/decrement operators permitted with bool?
>>
>>Increment yes, decrement no. b++ always means b=true (as far as we
>>could tell).
>
>That is very interesting.  What if b was *already* true before you incremented
>it??

Then it will remain true.

>>It is unclear what b-- means...
>
>This is a most remarkable assertion.  You have defined the result of b++ to
>always be true.  Why then does it NOT make sense for b-- to be defined to
>always yield false?

b++ was defined because there are existing programs that do
 bool b;
 ...
 b++;
but it is immediately depreciated.

Sure, the committee could also introduce b-- for symmetry and then
immediately depreciate it too, but they might as well introduce it
and then immediate abolish it, since it's not important for backwards
compatibility.

>(I sometimes wonder if the C++ committee isn't going out of their way to
>create inelegant asymmetries.)
>
>>...and it does not seem to be common.
>
>Gee, you mean to say that existing programs do not try to decrement their
>built-in type `bool' variables very much yet?  Facinating.

Of course not.  But existing programs _do_ increment variables of type
"bool", "boolean", "Bool", etc., and so it's necessary to allow incrementing
of bools to allow easy conversion of these programs.

--
Fergus Henderson                     fjh@munta.cs.mu.OZ.AU

In article <9334414.20749@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU (Fergus Henderson) writes:
>rfg@netcom.com (Ronald F. Guilmette) writes:
>
>>dag@control.lth.se (Dag Bruck) writes:
>>>In <comp.std.c++> kjhopps@mmm.com writes:
[...]
>>>>    4) Are increment/decrement operators permitted with bool?
>>>
>>>Increment yes, decrement no. b++ always means b=true (as far as we
>>>could tell).
[...]
>b++ was defined because there are existing programs that do
> bool b;
> ...
> b++;
>but it is immediately depreciated.
[...]
>[...] existing programs _do_ increment variables of type
>"bool", "boolean", "Bool", etc., and so it's necessary to allow incrementing
>of bools to allow easy conversion of these programs.

Why not "typedef bool int" in these cases? Are these existing programs so
numerous that it's worth polluting the language for evermore? Evidently the
committee thinks so.

Dave Cigna

In article <27289@alice.att.com> ark@alice.UUCP writes:

>In article <755255729snz@wslint.demon.co.uk> selliot@wslint.demon.co.uk writes:
>
>> And, since short-circuiting is impossible, we already have an XOR for bool.
>> It doesn't look like '^^' though - it looks like '!='.
>
>Unfortunately not: != doesn't convert its arguments to bool.  So,
>for instance, 1!=2 is true, but 1^^2 would be false.

But that is no longer 'bool'; the cases I am considering are
 false != false
 false != true
 true != false
 true != true

I am assuming that since both operands are 'bool', that conversion to 'short'
does not occur.

Of course, if mixed types are involved, normal promotions will occur,
'true' will be promoted to '1', and the programmer will get what (s)he deserves;
this could even be what (s)he intended.  Yecch!

--
Simon Elliott, Westinhouse Systems Ltd, CHIPPENHAM, Wilts, UK, SN15 1JJ
Westinghouse Systems Ltd is NOT affiliated with any other demon.co.uk site.

In article <hopps.755191629@mmm.com>, hopps@yellow.mmm.com (Kevin J
Hopps) writes:
> I have seen postings recently related to a new type, bool.  I am
> wondering
> about some particular aspects of its behavior.  In particular:
> [stuff deleted]
>
> Another comment.  As long as this major step is being considered, why
> not
> complete the set of boolean operators with respect to the bitwise
> operators?
> We have &, | and ^, but only && and ||.  Why not add ^^?

The "^^" operator doesn't make much sense, since there's no way to short-
circuit it the way "&&" and "||" can be short-circuited.

On the other hand, I see no reason why the bitwise operands can't be defined
for bool types.  This would not only add "xor" operations to bools, but also
allow compound assigments such as "|=", "&=", and "^=" to bools.

> --
> Kevin J. Hopps   e-mail: kjhopps@mmm.com
> 3M Company   phone: (612) 737-3300
> 3M Center, Bldg. 235-3B-16 fax: (612) 737-2700
> St. Paul, MN 55144-1000

--
       ___       _
   | __\_\_o____/_|            ,---------------------------,
   <[___\_\_-----< ------------|          ++don;           |
   |  o'                       `---------------------------'

hopps@yellow.mmm.com (Kevin J Hopps) writes:

>This seems quite inconsistent.  If b++ means b=true, to have b-- NOT mean
>b=false seems surprising.  But even if b-- were defined to work consistently
>with b++, IMHO those definitions are wrong.  I think both b++ and b-- should
>TOGGLE the value of b.

You have to look at _why_ the committee decided to allow b++ but immediately
depreciate it.  The reason seems to be that there was a lot of existing
code that did something like

 typedef int bool;
 ...
 bool b;
 ...
 if (...) b++;

Allowing b++ means that this code will work fine once the typedef is removed.
Not allowing b++ would mean that all such code would _have_ to be tediously
converted.  The committee has already depreciated b++, so compilers
should issue a warning (at least if full warnings are enabled) anyway.
This will encourage people to convert code like the above to b=1 or b=true,
without _forcing_ them to do so in order for it to work with the latest
release of their compiler.  [Suggesting that people continue using the
old release until they have converted such code would not be reasonable, since
the new release probably fixes some serious bug(s).]

So b++ was not allowed because the committee thought that you should be
able to do arithmetic on booleans, but in order to make conversion to
ANSI/ISO C++ easier.

>I submit that the effects of all operators on type bool need to be defined.

This is ridiculous.  Booleans are not numbers.  Implicit conversions
from bool to int and vice versa should be discouraged, not encouraged.
All compiler vendors should provide an option to warn about such
implicit conversions.

>Further, I submit that the proper definition should follow the principle
>of least surprise -- that the operators should do what most people find
>natural and intuitive.  Determining this may be difficult, but it is the
>best solution.

The point is that booleans are not numbers, so by the principle of least
surprise, attempting to do arithmetic on them should result in an error
(or at least a warning).  This is the case in every other language that
I know of that has a boolean type.

>I would be VERY interested in hearing what the C++ community thinks about
>the following (and I hope the committee is even more interested).
>Consider the following code fragment and then give your opinions.
>
>    extern bool x;
>    extern int i;
>    x = i;  // Legal?  What does it do?

Legal.  Equivalent to x = (i == 0).
Produces a warning, if compile with -Wbool (the compiler
flag for enabling warnings about implicit bool/int conversions.)

>    x = (bool)i; // Is this different from x=i?

You don't get a warning, even if -Wbool is specified.

>    i = x;  // Has i changed from before?

Yes.  This also produces a warning with -Wbool.

>    extern void* p;
>    x = p;  // Legal?  What does it do?

Again, equivalent to
 x = (p == 0);
except that it gives you a warning if you compile with -Wbool.

>    x = (bool)p; // Legal?  Different from x=p?

Same, but no warning.

>    extern double d;
>    x = d;  // Legal?  What does it do?

Produces a warning with -Wbool.
Equivalent to
 x = (d == 0);

>    x = (bool)d; // Legal?  Different from x=p?

Same, but no warning.

>    extern bool y, z;
>    x = y + z;  // Legal?  What does it do?
>    x = y - z;  // Legal?  What does it do?
>    x = y * z;  // Legal?  What does it do?
>    x = y / z;  // Legal?  What does it do?
>    x = y % z;  // Legal?  What does it do?
>    x = y | z;  // Legal?  What does it do?
>    x = y & z;  // Legal?  What does it do?
>    x = y ^ z;  // Legal?  What does it do?

All illegal.

>    x++;  // Legal?  What does it do?

Legal, but only for backwards compatability.
You get a warning whether or not -Wbool is enabled.
(The way to turn this warning off would be to use -traditional
or something like that.)

>    x--;  // Legal?  What does it do?
>    x += i;  // Legal?  What does it do?
>    x -= i;  // Legal?  What does it do?
>    x *= i;  // Legal?  What does it do?
>    x /= i;  // Legal?  What does it do?
>    x %= i;  // Legal?  What does it do?
>    x &= i;  // Legal?  What does it do?
>    x |= i;  // Legal?  What does it do?
>    x ^= i;  // Legal?  What does it do?

All illegal.

>Finally, as the first respondent, here are my opinions.  I find it
>very useful to think of a bool as a 1-bit unsigned, with all the integer
>operations behaving accordingly, except for assignment, where ALL nonzero
>values become 1 when stored in a bool.

You may find it useful, but I think most people would find it confusing.
It would be better if you used an explicit conversion to int if
you want bool to be a 1-bit unsigned integer.

--
Fergus Henderson                     fjh@munta.cs.mu.OZ.AU

I wrote:

>hopps@yellow.mmm.com (Kevin J Hopps) writes:
>
>>I submit that the effects of all operators on type bool need to be defined.
>
>This is ridiculous.

Having re-read my posting, I realize that comes across a little too strong.
It's not ridiculous, it's just something I don't agree with.
My apologies in case I offended anyone.

--
Fergus Henderson                     fjh@munta.cs.mu.OZ.AU

In <comp.std.c++> damian@cs.monash.edu.au (Damian Conway) writes:
>
>I was suggesting that if there is a built-in operator:
>
> bool operator<(bool,bool);
>
>Then the other operators taking bool as a 1st arg:
>
> template <class notBool>
> bool operator<(bool,notBool);
>
>ought NOT be defined, thereby catching at compile-time the much-lamented:
>
> if (a<b<c)
>  DoSomethingUnexpected();

I see the problem, and I agree that would be good if we could catch
that one.  The underlying problem is that C++ has a fairly extensive
set of automatically applied conversions; of course, what we think is
a problem in this context also makes the language easier to use in
other contexts.

Back to bool: the "a<b<c" problem could be solved (I think) by not
allowing the automatic promotion from bool to int.  However, that is
not feasible because it would instantly break every existing program.
Take a program that looks like this:

 extern void f(int);
 :
 f(x < 4);

The relational expression "x < 4" has a value of type bool (new
rules).  Because of the automatic promotion to int, this code will
still compile and work as it did before, calling f(int).  Well, you
could of course fix the program by changing f(int) to f(bool), but
that may not be so easy, for example, if f(int) really is a library
function.

Note however that you can make a step-wise conversion to bool by
adding an overloading f(bool):

 inline void f(bool b) { f(int(b)); }

This enables you to turn on a compiler switch to warn about all sorts
of implicit conversions, without being swamped by warnings for all
calls of f.

    -- Dag

In <comp.std.c++> kjhopps@mmm.com writes:
>
>I submit that the effects of all operators on type bool need to be defined.

I disagree.  I see no reason to introduce reduntant operators just
because they exist, and I found some of your proposed resolution
awkward.

>Further, I submit that the proper definition should follow the principle
>of least surprise -- that the operators should do what most people find
>natural and intuitive.  Determining this may be difficult, but it is the
>best solution.

I agree completely.  It is precisely because of our differences in
opinion that we have decided to not define all operators.

Please remember that Andrew Koenig and I wrote the proposal, we were
both at the meeting and champoined it, so most likely our preferences
would have been adopted (and your preferences would have been run
over).  It would also have been very difficult to arrive at a
concensus over an issue where people have widely different preferences.

>Finally, as the first respondent, here are my opinions.  I find it
>very useful to think of a bool as a 1-bit unsigned, with all the integer
>operations behaving accordingly, except for assignment, where ALL nonzero
>values become 1 when stored in a bool.

I don't regard booleans to be one-bit numbers.  To me that just seems
like a hang-over from the strange C-notion where characters and
booleans are numbers.  Ok, I'm deliberately exagerating, but please
accept that there may be a different view.

Besides, a bool must promote to a SIGNED integer, because boolean
expressions in C and C++ today are signed integers.  For example,

 void f(int);
 void f(unsigned int);

 f(x < 3);

That will pick up f(int).

     -- Dag

In <comp.std.c++> rfg@netcom.com (Ronald F. Guilmette) writes:
>>Increment yes, decrement no. b++ always means b=true
>
>That is very interesting.  What if b was *already* true before you incremented
>it??
>
>>It is unclear what b-- means...
>
>This is a most remarkable assertion.  You have defined the result of b++ to
>always be true.  Why then does it NOT make sense for b-- to be defined to
>always yield false?

I think you have already answered your question.  Given the following
program fragment:

 int b = 0;
 b++; b++; b--;

Under the current C and C++ rules, b is still true (i.e., non-zero).

Changing the type of b to the new built-in bool type, under our rules
the program would be illformed and cause a compile-time error.

Under your proposal (b-- yields false), the program would be
syntactically correct, but its meaning would quietly have changed.
We thought that was worse than a compile-time error.

>(I sometimes wonder if the C++ committee isn't going out of their way to
>create inelegant asymmetries.)

We have to keep in touch with reality, and reality is not always pretty.
I think we're doing pretty well.

     -- Dag

fjh@munta.cs.mu.OZ.AU (Fergus Henderson) writes:

>rfg@netcom.com (Ronald F. Guilmette) writes:


>b++ was defined because there are existing programs that do
> bool b;
> ...
> b++;
>but it is immediately depreciated.

>Sure, the committee could also introduce b-- for symmetry and then
>immediately depreciate it too, but they might as well introduce it
>and then immediate abolish it, since it's not important for backwards
>compatibility.

>>(I sometimes wonder if the C++ committee isn't going out of their way to
>>create inelegant asymmetries.)
>>
>>>...and it does not seem to be common.
>>
>>Gee, you mean to say that existing programs do not try to decrement their
>>built-in type `bool' variables very much yet?  Facinating.

>Of course not.  But existing programs _do_ increment variables of type
>"bool", "boolean", "Bool", etc., and so it's necessary to allow incrementing
>of bools to allow easy conversion of these programs.

Either I am missing somwthing here, or this is all a lot of bull. If your
headers define a type bool, it overrides the new type anyway. No old code
is broken. When you remove the typedef, a few dozen replacements of
(anyway nonsensical) codes will suffice to make the program behave proper.

If you have no idea what the program does, and do not feel like fooling around
with it, you should not be deleteing the typedef bool first hand. If you have
enough knowledge to delete it, you are very likely able to make the program
work again as well.

One might even argue that bool should get more than two values. There might
be an enum bool {false, maybe, true}; somewhere, and interpreting
++boolvar might break code with the new behaviour. I think that arithmetic
operators have no reason to be found in a bool type, making the feature
much uglier. And, as already said, no code is broken anyway, and adaption
is easy.

If no code is to be broken, the we might as well define typedef int bool;
#define false 0
#define true 1
by default and have the "new" behaviour. I consider this nonsense. If
something redundant (and bool is redundant) is introduced, then to
encourage better programming. And long enough have booleans and integers
been muddled.

--
 David Kastrup        dak@pool.informatik.rwth-aachen.de
 Tel: +49-241-72419 Fax: +49-241-79502
 Goethestr. 20, D-52064 Aachen

In <comp.std.c++> dak@hathi.informatik.rwth-aachen.de (David Kastrup) writes:
>
>Either I am missing somwthing here, or this is all a lot of bull. If your
>headers define a type bool, it overrides the new type anyway.

Under the new rules "bool" will be a reserved word, so

 typedef int bool;

is no longer correct.  Any program that has such a typedef must be
changed, by removing the typedef, in order to compile.  The proposal
was deliberately written (and compromises introduced) to make the
transition as easy as possible.

>If no code is to be broken, the we might as well define typedef int bool;
>#define false 0
>#define true 1
>by default and have the "new" behaviour.

With the adopted proposal you also get overloading on bool;
typedef'ing bool to some other type will not do that.


    -- Dag

I have seen postings recently related to a new type, bool.  I am wondering
about some particular aspects of its behavior.  In particular:
    1) what happens when an int with value other than 0 or 1 is assigned
       to a bool?
    2) What happens when various types are cast to a bool?  Do all nonzero
       values become the single representation for "true"?  Perhaps this
       answers question 1.
    2) How big is a bool?
    3) Can I use a bool as a bit field, i.e. (bool x:1)?
    4) Are increment/decrement operators permitted with bool?
    5) What binary operators are permitted between bools?

Another comment.  As long as this major step is being considered, why not
complete the set of boolean operators with respect to the bitwise operators?
We have &, | and ^, but only && and ||.  Why not add ^^?
--
Kevin J. Hopps   e-mail: kjhopps@mmm.com
3M Company   phone: (612) 737-3300
3M Center, Bldg. 235-3B-16 fax: (612) 737-2700
St. Paul, MN 55144-1000

In <comp.std.c++> kjhopps@mmm.com writes:
>I have seen postings recently related to a new type, bool.  I am wondering
>about some particular aspects of its behavior.  In particular:
>    1) what happens when an int with value other than 0 or 1 is assigned
>       to a bool?
>    2) What happens when various types are cast to a bool?  Do all nonzero
>       values become the single representation for "true"?  Perhaps this
>       answers question 1.

Yes, it does.  Non-zero becomes true.

>    2) How big is a bool?

Implementation defined, but sizeof(bool) >= sizeof(char).

>    3) Can I use a bool as a bit field, i.e. (bool x:1)?

Yes, you can, but arrays cannot be bit-packed (because a bool must
be an adressable unit, i.e., sizeof(bool) >= 1).

>    4) Are increment/decrement operators permitted with bool?

Increment yes, decrement no. b++ always means b=true (as far as we
could tell).  It is unclear what b-- means, and it does not seem to be
common.

>    5) What binary operators are permitted between bools?

Operators ! && and || take bool operands.  Note however that bool
promotes to int, which means that b1 ^ b2 is defined as

 int(b1) ^ int(b2)

Nobody has bothered to propose operator ^^.


    -- Dag

I take it comparison operators (< > <= >=) will work by conversion to int?

Might have been nice to invalidate these ops for a bool first argument, thereby
nipping in the bud the odious:

 if ( 1 < x < 10 ) {...

construct.

Yeah, I know it would break existing code, but such code probably deserves to be
broken :-)

damian
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  who: Damian Conway                 email: damian@bruce.cs.monash.edu.au
where: Dept. Computer Science        phone: +61-3-565-5184
       Monash University               fax: +61-3-565-5146
       Clayton 3168                  quote: "A pessimist is never disappointed."
       AUSTRALIA

kjhopps@mmm.com writes:
>Another comment.  As long as this major step is being considered, why not
>complete the set of boolean operators with respect to the bitwise operators?
>We have &, | and ^, but only && and ||.  Why not add ^^?

Presumably this would be like && or ||, only implement exclusive-or,
after coercing the arguments to boolean type (or, in C, to 0/1 values).

A major feature of the && and || operators is that the second argument is
evaluated only if necessary to determine the value of the expression.
This feature is useless for ^^, since the exclusive or can't be
short-circuited; you always need to see both arguments.  For bool-valued
expressions, ^ will be equivalent; bool(e1) ^ bool(e2) would give the same
result as e1 ^^ e2.  However, bool(e1) & bool(e2) isn't the same as
e1&&e2, since the side effects of e2 don't occur if e1 is false.





--
-- Joe Buck jbuck@synopsys.com
Posting from but not speaking for Synopsys, Inc.
Formerly jbuck@<various-hosts>.eecs.berkeley.edu

In article <1993Dec7.012731.21988@Synopsys.Com> jbuck@synopsys.com writes:

>kjhopps@mmm.com writes:
>>Another comment.  As long as this major step is being considered, why not
>>complete the set of boolean operators with respect to the bitwise operators?
>>We have &, | and ^, but only && and ||.  Why not add ^^?
>
>A major feature of the && and || operators is that the second argument is
>evaluated only if necessary to determine the value of the expression.
>This feature is useless for ^^, since the exclusive or can't be
>short-circuited; you always need to see both arguments.

And, since short-circuiting is impossible, we already have an XOR for bool.
It doesn't look like '^^' though - it looks like '!='.

--
Simon Elliott, Westinghouse Systems Ltd, CHIPPENHAM, Wilts, UK, SN15 1JJ
Westinghouse Systems Ltd is NOT affiliated with any other demon.co.uk site.

In <comp.std.c++> damian@cs.monash.edu.au (Damian Conway) writes:
>I take it comparison operators (< > <= >=) will work by conversion to int?

I'm not sure I understand what you ask, but the result of a
comparison, e.g.

 x < 10

returns a bool result, which if needed gets promoted to int.

I believe the answer to your question is "yes."


   -- Dag

In <comp.std.c++> jbuck@synopsys.com (Joe Buck) writes:
>For bool-valued
>expressions, ^ will be equivalent; bool(e1) ^ bool(e2) would give the same
>result as e1 ^^ e2.

Assuming that ^^ returns a bool value, it would really be

 bool(bool(e1) ^ bool(e2))

which could have an impact on your overloading.

Sorry for nit-picking, but you get that way in a standards committee.


    -- Dag

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

>In <comp.std.c++> damian@cs.monash.edu.au (Damian Conway) writes:
>>I take it comparison operators (< > <= >=) will work by conversion to int?

>I'm not sure I understand what you ask, but the result of a
>comparison, e.g.

> x < 10

>returns a bool result, which if needed gets promoted to int.

Sorry, I'll be clearer. Suppose I write:

 bool a,b;
   :
   :
   :
 if (a < b)
  DoSomething();
   :
   :

Presumably this is implemented as (or at least equivalent to):

 if (int(a) < int(b))
  DoSomething();

I was suggesting that if there is a built-in operator:

 bool operator<(bool,bool);

Then the other operators taking bool as a 1st arg:

 template <class notBool>
 bool operator<(bool,notBool);

ought NOT be defined, thereby catching at compile-time the much-lamented:

 if (a<b<c)
  DoSomethingUnexpected();

damian


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  who: Damian Conway                 email: damian@bruce.cs.monash.edu.au
where: Dept. Computer Science        phone: +61-3-565-5184
       Monash University               fax: +61-3-565-5146
       Clayton 3168                  quote: "A pessimist is never disappointed."
       AUSTRALIA

In article <2dvt4e$nme@nic.lth.se> dag@control.lth.se (Dag Bruck) writes:
>In <comp.std.c++> kjhopps@mmm.com writes:
>>I have seen postings recently related to a new type, bool.  I am wondering
>>about some particular aspects of its behavior.  In particular:
>>    1) what happens when an int with value other than 0 or 1 is assigned
>>       to a bool?
>>    2) What happens when various types are cast to a bool?  Do all nonzero
>>       values become the single representation for "true"?  Perhaps this
>>       answers question 1.
>
>Yes, it does.  Non-zero becomes true.

What types EXACTLY may be cast to type bool?  Integral types?  Floating-
point types?  Pointer types?  Enumeration types?  Struct/union/class types?
Reference types?  Pointer to member types?

>>    4) Are increment/decrement operators permitted with bool?
>
>Increment yes, decrement no. b++ always means b=true (as far as we
>could tell).

That is very interesting.  What if b was *already* true before you incremented
it??

>It is unclear what b-- means...

This is a most remarkable assertion.  You have defined the result of b++ to
always be true.  Why then does it NOT make sense for b-- to be defined to
always yield false?

(I sometimes wonder if the C++ committee isn't going out of their way to
create inelegant asymmetries.)

>...and it does not seem to be common.

Gee, you mean to say that existing programs do not try to decrement their
built-in type `bool' variables very much yet?  Facinating.

--

-- Ronald F. Guilmette, Sunnyvale, California -------------------------------
------ domain address: rfg@netcom.com ---------------------------------------
------ uucp address: ...!uunet!netcom.com!rfg -------------------------------

In article <2e1bik$elr@nic.lth.se> dag@control.lth.se (Dag Bruck) writes:

> Assuming that ^^ returns a bool value, it would really be
>
>  bool(bool(e1) ^ bool(e2))
>
> which could have an impact on your overloading.

Or

 (bool(e1) != bool(e2))
--
    --Andrew Koenig
      ark@research.att.com

In article <755255729snz@wslint.demon.co.uk> selliot@wslint.demon.co.uk writes:

> And, since short-circuiting is impossible, we already have an XOR for bool.
> It doesn't look like '^^' though - it looks like '!='.

Unfortunately not: != doesn't convert its arguments to bool.  So,
for instance, 1!=2 is true, but 1^^2 would be false.
--
    --Andrew Koenig
      ark@research.att.com

In article <damian.755223171@bruce.cs.monash.edu.au> damian@cs.monash.edu.au (Damian Conway) writes:

> I take it comparison operators (< > <= >=) will work by conversion to int?

By converting their operands to int, yes.  Their results will now be bool.

> Might have been nice to invalidate these ops for a bool first argument, thereby
> nipping in the bud the odious:
>
>  if ( 1 < x < 10 ) {...
>
> construct.

Relational operators on Booleans are actually sometimes useful.
There's nothing to stop compiler writers from warning about dubious
cases if they think their users want it.

Obscure fact: `and,' `or,' `nand,' `nor,' and the six relational operators
exhaust the set of non-trivial Boolean functions on two operands.
--
    --Andrew Koenig
      ark@research.att.com