In article <9521600.9005@mulga.cs.mu.OZ.AU>,
Fergus Henderson <fjh@munta.cs.mu.OZ.AU> wrote:

> But that's the whole point: every man and his dog uses a different
> type to store boolean values.  This causes a real software engineering
> problem, especially when you are using several different libraries,
> all of which define `bool' (incompatibly).  It makes sense to standardize
> on just *one* boolean type.

There is a big difference between standardizing on one boolean type and
adding it to the language as a built-in. Unfortunately, providing a
boolean type at the library level does not help with the problem that
some people would like conditional operators to return boolean instead
of 0/1. This cannot be patched into the language without breaking lots
of old code.

I maintain, as far as C is concerned, that adding a built-in boolean
type will gratuitiously complicate the language to little gain and
should therefore be avoided. For C++, things may be different, but then
I don't use C++. There is no need to turn C into C++ by stealth.

Anselm
--
Anselm Lingnau ......................... lingnau@tm.informatik.uni-frankfurt.de
Fine words and an insinuating appearance are seldom associated with true
virtue.                                               --- Confucius, *Analects*

Anselm Lingnau (lingnau@tm.informatik.uni-frankfurt.de) wrote:
: In article <9521600.9005@mulga.cs.mu.OZ.AU>,
: Fergus Henderson <fjh@munta.cs.mu.OZ.AU> wrote:

: There is a big difference between standardizing on one boolean type and
: adding it to the language as a built-in. Unfortunately, providing a
: boolean type at the library level does not help with the problem that
: some people would like conditional operators to return boolean instead
: of 0/1. This cannot be patched into the language without breaking lots
: of old code.

Provided an automatic conversion is made bool<->int then no code should break
[it is effectivly an invisible change]. One could even make bool an itegral
type like an enum with two values in which case the conversion comes for free.
For many people that is enough - it would stop the proliferation of bool like
typedefs. I think that this is worth doing.

However to get any benifit of type checking one needs to restrict int->bool
conversion which would break some code. Provided one permits this to happen
automatically in the context of conditionals [ if() ?: && !! while() ]
and also allows ptr->bool in these contexts too then very little code will
break as these are the only places existing code would need to do this
conversion. If one started changing parameters to standard library functions
to bool then this would cause code to break with restricted int->bool
conversions.

Note there is nothing to stop compilers issueing warnings rather than errors
for int->bool conversions and continuing to compile. There are enough ANSI
compilers out there that still regard int<->ptr conversions as only a warning!

--
Stephen Baynes                              baynes@mulsoc2.serigate.philips.nl
Philips Semiconductors Ltd
Southampton                                 My views are my own.
United Kingdom

Anselm Lingnau (lingnau@tm.informatik.uni-frankfurt.de) wrote:
|> In article <KANZE.95Aug3174437@slsvhdt.lts.sel.alcatel.de>,
|> James Kanze US/ESC 60/3/141 #40763 <kanze@lts.sel.alcatel.de> wrote:

|> > The analogy with characters in Pascal breaks down in that the compiler
|> > never needs a character type; the type *doesn't* exist in C (yet). [...]

|> I still don't see a fundamental difference between the convention that
|> `0' is taken as `false' and `non-0' is taken as `true' in conditionals
|> and the convention that certain (small, as yet) integers correspond to
|> characters that you can print.

|> If anything, the `char' situation is worse: there is no guarantee that
|> the value 65 will get you an `A', for example, while the correspondence
|> between integers and `truth values' is fixed. And what sense is there in
|> having a `char' type that you can *increment* -- in a German locale,
|> should `char c = 'A'; ++c' give you `B' or `A-umlaut'? This seems to me
|> ample justification for a true character type where such operations are
|> outlawed, so we can avoid subtle errors :^)

The only case in C/C++ where incrementing a `character' (as opposed to a
`char' type) is portably defined is for digits: '0' + n (for n <= 9)
gives the character representation of n.  As this function is better
done with a table anyway (think about expanding it to handle
hexadecimal.  Remember, 'A' + 5 is *not* guaranteed to be 'F'.), there
is some justification in what you say.

In fact, there *is* some discussion in certain cercles that the basic
character type should *not* be `char', but wchar_t.  I do know that
allowing 8 bit signed `char' makes my life more difficult, and I'm not
concerned about internationalization -- if it can handle the French
characters, that's enough (for many applications).

All more arguements for having a special character type:-).

|> > That's one solution, but it doesn't work in C++ due to function
|> > overloading.  I will admit, however, that there is a definite conflict
|> > between what I would really like to have, and what to do with existing
|> > code.

|> I can see the justification for a built-in Boolean type as far as C++
|> is concerned. IMHO, it does not follow that C needs to go along with it.
|> C is nice, comparatively simple and *small*. Keep it that way.

Overall, I agree.  If I want C++ (and I generally do), I know where to
find it.  But I'd like to keep C (as a separate and different language)
available as an option.  I just don't see where a boolean type (or, for
example, C++ style comments) will make C significantly less simple or
bigger.
--
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils en informatique industrielle--
                             --Beratung in industrieller Datenverarbeitung

In article <9521600.9005@mulga.cs.mu.OZ.AU>, fjh@munta.cs.mu.OZ.AU (Fergus Henderson) writes
+ But that's the whole point: every man and his dog uses a different
+ type to store boolean values.  This causes a real software engineering
+ problem, especially when you are using several different libraries,
+ all of which define `bool' (incompatibly).  It makes sense to standardize
+ on just *one* boolean type.


Maibe each man and his dog needs his own type for that.
But I wunder why anione needs anie "boolean" type.

In article <KANZE.95Aug3174437@slsvhdt.lts.sel.alcatel.de>,
James Kanze US/ESC 60/3/141 #40763 <kanze@lts.sel.alcatel.de> wrote:

> I agree that with experience, one can get used to
> reading anything, but why this insistance on making it hard for the
> reader?

Well, nobody *forces* you to say `if (ptr)'. You can always put in the
explicit comparison if you're feeling nice :^)

> The analogy with characters in Pascal breaks down in that the compiler
> never needs a character type; the type *doesn't* exist in C (yet). [...]

I still don't see a fundamental difference between the convention that
`0' is taken as `false' and `non-0' is taken as `true' in conditionals
and the convention that certain (small, as yet) integers correspond to
characters that you can print.

If anything, the `char' situation is worse: there is no guarantee that
the value 65 will get you an `A', for example, while the correspondence
between integers and `truth values' is fixed. And what sense is there in
having a `char' type that you can *increment* -- in a German locale,
should `char c = 'A'; ++c' give you `B' or `A-umlaut'? This seems to me
ample justification for a true character type where such operations are
outlawed, so we can avoid subtle errors :^)

> That's one solution, but it doesn't work in C++ due to function
> overloading.  I will admit, however, that there is a definite conflict
> between what I would really like to have, and what to do with existing
> code.

I can see the justification for a built-in Boolean type as far as C++
is concerned. IMHO, it does not follow that C needs to go along with it.
C is nice, comparatively simple and *small*. Keep it that way.

Anselm
--
Anselm Lingnau ......................... lingnau@tm.informatik.uni-frankfurt.de
Windows/NT - From the people who brought you EDLIN.
                                              --- Herb.Peyerl@novatel.cuc.ab.ca

kanze@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763) wrote:

>Actually, if I remember your proposal correctly, the main
>justification given for the bool type was existing practice: every
>major library has one.  And most of the examples were in fact C, not
>C++.  (A quick grep over the X11 include files, for example reveals
>typedefs/#defines for Boolean, boolean, Bool and BOOL.)

Yes. Other places I have also seen Flag, flag, and FLAG and Logical.

>Obviously, some programmers *have* felt the need for such a type.

I was one of the people who wanted a bool type in the C standard before
it was finalized simply so that I didn't have to define it myself and
worry about coliding with some other #include file (e.g. one library has
"#define bool int;" and I try to do "enum bool { FALSE, TRUE };".

I have never found a need to overload on a boolean expression, so I
don't mind bool being a synonym for int. I just want to use bool (and
TRUE and FALSE)  as a way of making code more self-documenting.
Therefore, I would be happy if bool, TRUE, and FALSE were just made part
of the standard library (in stdlib.h, perhaps).

BTW, there is one programming error that can be attributed to the
absense of a real boolean type. The following code is bad style, but I
do see it (and have to debug it) sometimes:

 typedef int bool;
 #define FALSE 0
 #define TRUE 1

 int f();
 bool x = f();
 if (x == TRUE)
  // do something

The problem being, of course, that x could have a non-false value of
non-one. A built in bool type could improve this situation. A C++ class
could also solve this problem (but would not be the automatic result of
comparsion operators like operator <(int, int) ). In the following
(untested) class the assignment and comparison operators prevent a bool
objects from ever assuming values other than TRUE or FALSE. Comparisons
to TRUE will always (I think) be interpreted as checks for non-zero:

 class bool
 {
  // Class invarient: 0 <= val <= 1
  int val;
     public:
  bool(int i = 0) : val(i != 0) { } // ensure class invarient
  bool(const bool& b) : val(b.val) { }
  operator int() const { return val; }
  bool& operator=(int i) { val = (i != 0); return *this; }
  friend int operator==(bool b1, bool b2)
   { return b1.val == b2.val; }
  friend int operator==(bool b, int i)
   { return b.val == (i != 0);  }
  friend int operator==(int i, bool b)
   { return b.val == (i != 0);  }
 };

 const bool FALSE(0), TRUE(1);
-------------------------------------------------------------
Pablo Halpern                   phalpern@truffle.ultranet.com

matt@godzilla.EECS.Berkeley.EDU (Matt Austern) writes:

>halasz@caip.rutgers.edu writes:
>
>> This exactlie reflects my point, that there is no special plase
>> in programming for a two-stated type.  It seldom is thus needed,
>> certainlie not enough for a new type & kieword.
>
>I tend to agree, actually: it would have been nice if C had had a
>boolean type from the very beginning, but it doesn't take much effort
>to get used to the idea that truth values are represented by integers.

Sure it doesn't take long to get used to the idea of using 0 and 1, but
the point is that programmers should express their intent in the source
code.  0 and 1 are just as easy to write as true or false (even easier,
since they are fewer keystrokes), but they can be significantly more
difficult to read.

--
Fergus Henderson              | Designing grand concepts is fun;
fjh@cs.mu.oz.au               | finding nitty little bugs is just work.
http://www.cs.mu.oz.au/~fjh   | -- Brooks, in "The Mythical Man-Month".
PGP key fingerprint: 00 D7 A2 27 65 09 B6 AC  8B 3E 0F 01 E7 5D C4 3F

In article <house.807244163@helios>, house@helios.usq.EDU.AU says...
>
>jim.fleming@bytes.com (Jim Fleming) writes:
>
>>[huge amount of quoted article then a few lines of response]
>
>Fleming, you're an absolute moron. You've been around long enough to
>know how to use a newsreader and trim articles,
@@@@@@@
[snip]
>--
>
>Ron House.         USQ                   | A nonviolent diet is the
>(house@usq.edu.au) Toowoomba, Australia. | foundation for a nonviolent
world.
@@@@@@

Thanks for your comments...as you can see above...I snipped most of
your comments...

Don't feel like you have to give me the benefit of the doubt...
 ...I am not looking for anything from you...
  ...feel free to ignore my postings...

Despite people like you...the story of C+@ will be told...
 ...it is an interesting story to some people...
  ...feel free to ignore my postings...

Thanks for *giving* me the benefit of the doubt...
 ...I doubt if I will ever be able to repay you...

@@@@@@
--
Jim Fleming            /|\      Unir Corporation       Unir Technology, Inc.
jrf@tiger.bytes.com  /  | \     One Naperville Plaza   184 Shuman Blvd. #100
%Techno Cat I       /   |  \    Naperville, IL 60563   Naperville, IL 60563
East End, Tortola  |____|___\   1-708-505-5801         1-800-222-UNIR(8647)
British Virgin Islands__|______ 1-708-305-3277 (FAX)   1-708-305-0600
                 \__/-------\__/       http:199.3.34.13 telnet: port 5555
Smooth Sailing on Cruising C+@amarans  ftp: 199.3.34.12 <-----stargate----+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\____to the end of the OuterNet_|

In article oqt@News1.mcs.net, jim.fleming@bytes.com (Jim Fleming) writes:
>
>Despite people like you...the story of C+@ will be told...
> ...it is an interesting story to some people...

I am breaking here my self-imposed rule of never responding to a post
from Jim Fleming -- it's my rule, I can break it if I want -- because of
the gross falsehood he presents.

For months, I and others begged in this forum and by private email for information
about C+@: what exactly is it, where can we get a language specification,
what implementations exist, how can we get an implementation, and so on.

So far as I have been able to determine, Fleming consistently refused to
provide any of this information. His answers were never more specific than
"it's great, it's wonderful, implementations are around, you could
probably find one."

Fleming did at one point offer to send a floppy disk to anyone who mailed
him $10 US in cash. He never did say what would be on the floppy disk.
Since I can get about 20 floppy disks at my local computer store for $10,
this didn't seem like a very good offer.

So Jim, I'm saying again, "Put up or shut up." It appears that C+@ is no
more than a figment of your very fertile imagination. Prove me wrong, or
stop mentioning it in this forum, which is, after all, supposed to be
about C++.

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

clamage@Eng.Sun.COM (Steve Clamage) writes:
...
> For months, I and others begged in this forum and by private email for information
> about C+@: what exactly is it, where can we get a language specification,
> what implementations exist, how can we get an implementation, and so on.
...
> So Jim, I'm saying again, "Put up or shut up." It appears that C+@ is no
> more than a figment of your very fertile imagination. Prove me wrong, or
> stop mentioning it in this forum, which is, after all, supposed to be
> about C++.

Sorry, but he has at one time or another (in at least one out of very
many postings) provided such a path, because I followed it sometime
long ago and retrieved a 58-page document titled:

  "The C+@ Pr ogramming Language:
       Language Definition"

by:

  Software Infrastructure Group
   AT&T Bell Laboratories
   Naperville, IL 60566

This document was apparently produced in 1990.  I think that this
language was once known as "Calico", though I'm not sure.

speaking for myself,

David Chase

In <DCJAon.7tH@research.att.com>, Andrew Koenig (ark@research.att.com) wrote
: In article <DCFHJq.JC3@isgtec.com> pcurran@isgtec.com (Peter Curran) writes:

: > This is true, but one of the great strengths of C++ is supposed to be
: > it wonderful type definition facilities.  If it is necessary to build
: > as simple a type as this into the language, the whole thing begins to
: > look pretty silly.

: The alternative is to change built-in operators like < to yield a
: user-defined type, which is even more silly.
: --
:     --Andrew Koenig
:       ark@research.att.com

So, we're agreed - no matter what you do with C++, it's silly :-)

(To clarify, on a more serious level - IMHO C++ was an interesting and
valuable experiment, but we've learned its lessons and it's time to
move on.  I don't think the apparently-infinite set of patches that
have been/are being done to it in an effort to "finish" it are ever
going result in an adequate language.)

--
Peter Curran                                        pcurran@isgtec.com
ISG Technologies, Inc                              (905) 672-2100 X315
6509 Airport Road,        http://www.isgtec.com     Fax (905) 672-2307
Mississauga, Ontario, Canada                   Usual disclaimers apply

In article <3va81j$b4c@deneb.tm.informatik.uni-frankfurt.de> Anselm
Lingnau <lingnau@tm.informatik.uni-frankfurt.de> writes:

|> In article <KANZE.95Jul26122240@slsvhdt.lts.sel.alcatel.de>,
|> James Kanze US/ESC 60/3/141 #40763 <kanze@lts.sel.alcatel.de> wrote:

|> > The result of a lack of an explicit boolean type results in precisely
|> > the ambiguities you are talking about.  How often does one see:
|> >
|> >  if ( strcmp( s1 , s2 ) )  /*  strings are not ==   */
|> >  if ( p )                  /*  pointer is not NULL  */
|> >  if ( *p )                 /*  not at end of string */
|> >
|> > Such code has become so prevalent in C that some people actually argue
|> > that it is good, or readable.

|> I can see a problem with the strcmp(), which is why I use something like

|>  #define STR_EQ(a, b) (strcmp((a), (b)) == 0)

|> But this has nothing to do with the boolean type issue. As far as the
|> `hacky' implicit comparison to 0 in the last two examples go, as a C
|> programmer with some experience I find their meaning completely obvious,
|> though I don't use them in code that I write (well, not often, anyway).

And why not:-)?  I agree that with experience, one can get used to
reading anything, but why this insistance on making it hard for the
reader?

|> > My point is precisely that C has, at least implicitly, a built-in
|> > boolean type.  You cannot have `if' or `while' otherwise.

|> I don't buy that. The zero/non-zero convention as used by conditionals
|> doesn't make `int' a `built-in boolean type'. C doesn't have a built-in
|> character type either (the way Pascal does), and that doesn't keep us
|> from using `char' to do string operations. Anybody want to argue for
|> a built-in character type that's not an integer type?

I don't claim that `int' is a `built-in boolean type'.  What I am
saying is the the compiler requires a logical predicate to decide a
two way branch.  This predicate is your built-in boolean type.  Now,
there is no expression in C which evaluates to this type, so the
compiler is obliged to ``convert'' an int or a pointer to such a
predicate.

The analogy with characters in Pascal breaks down in that the compiler
never needs a character type; the type *doesn't* exist in C (yet).  As
one who has to work in non-English speaking environments, however, I
can tell you that this is a real problem; some of the French and
German characters are negative in my environment, which makes ctype
problematic, even with locale correctly set.

|> > (Seriously, the problem of breaking existing code means that it is
|> > impossible to adapt anything more than a compromize solution.)

|> Exactly. So all you end up with is a gratuitiously complex language
|> definition. It would be more worthwhile to fix your compiler to emit
|> a warning if you use an implicit comparison to 0, rather than force
|> a built-in boolean type down everybody's throats.

That's one solution, but it doesn't work in C++ due to function
overloading.  I will admit, however, that there is a definite conflict
between what I would really like to have, and what to do with existing
code.
--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                              -- Beratung in industrieller Datenverarbeitung

In article <DCBsLu.n1A@research.att.com> ark@research.att.com (Andrew
Koenig) writes:

|> In article <1995Jul26.030356.21528@sq.sq.com> msb@sq.sq.com (Mark Brader) writes:

|> > No, that's not what I'm saying.  I'm saying that there is no justification
|> > for adding to the language a type specific to boolean values, when such
|> > values can already be manipulated in any of several types.  (One of which
|> > is indeed int.)  Dennis Ritchie got it right.

|> The justification is:

|>  1. Unless bool is a separate type, there's no way to overload on it.

|>  2. It can't be a user-defined type because there's no way
|>     for users to define the type of expressions like 3<4.

|> Because C doesn't have overloading, this is much less of an issue for
|> C than it is for C++.

Actually, if I remember your proposal correctly, the main
justification given for the bool type was existing practice: every
major library has one.  And most of the examples were in fact C, not
C++.  (A quick grep over the X11 include files, for example reveals
typedefs/#defines for Boolean, boolean, Bool and BOOL.)

Obviously, some programmers *have* felt the need for such a type.
--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                              -- Beratung in industrieller Datenverarbeitung

>|> >As someone else pointed out, bool++ is a nice shorthand for test-and-set.

I am surprised that no-one else has pointed out that test-and-set is
*WRONG* for initialisation.  This should be another nail in the coffin
of bool++.  Let me explain.

In most cases, the right way to code one-time initialisation is

 {
     static int initialised = 0;

     if (!initialised) {
  /* many lines of initialisation code */
  initialised = 1;
     }
     ...
 }

The 'initialised' flag should mean "initialisation has been COMPLETED".
If you set the flag too early, as in

     if (!initialised) {
  initialised = 1;
  /* many lines of initialisation code */

then you _may_ never be sure that initialisation has been done.   Why?
Think about signals, signal handlers, longjmp(), and so on.

I learned about this problem only a year after I started coding C.

--
"conventional orthography is ... a near optimal system for the
 lexical representation of English words." Chomsky & Halle, S.P.E.
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.

msb@sq.sq.com (Mark Brader) writes:

>I'm saying.  I'm saying that there is no justification
>for adding to the language a type specific to boolean values, when such
>values can already be manipulated in any of several types.

But that's the whole point: every man and his dog uses a different
type to store boolean values.  This causes a real software engineering
problem, especially when you are using several different libraries,
all of which define `bool' (incompatibly).  It makes sense to standardize
on just *one* boolean type.

--
Fergus Henderson              | Designing grand concepts is fun;
fjh@cs.mu.oz.au               | finding nitty little bugs is just work.
http://www.cs.mu.oz.au/~fjh   | -- Brooks, in "The Mythical Man-Month".
PGP key fingerprint: 00 D7 A2 27 65 09 B6 AC  8B 3E 0F 01 E7 5D C4 3F

In article <DCFHJq.JC3@isgtec.com> pcurran@isgtec.com (Peter Curran) writes:

> This is true, but one of the great strengths of C++ is supposed to be
> it wonderful type definition facilities.  If it is necessary to build
> as simple a type as this into the language, the whole thing begins to
> look pretty silly.

The alternative is to change built-in operators like < to yield a
user-defined type, which is even more silly.
--
    --Andrew Koenig
      ark@research.att.com

In article <3uuprl$frm@newsbf02.news.aol.com>, ffarance@aol.com says...
>
>> From: msb@sq.sq.com (Mark Brader)
>>
>> > There's absolutely no justification in adding all sorts of stupid and
>> > non-obvious quirks to the bool type (such as the example under
>discussion
>> > of allowing the ++ operator) ...
>>
>> If we're talking about C (it's hard to tell, since this entire thread
>> is cross-posted), I'd say that there's absolutely no justification for
>> adding a "bool type" to the language in the first place, and good reason
>> (as covered in the comp.lang.c FAQ list) not to do so.
>
>A boolean type isn't really required in C, assuming you believe that
>"bool" is just another name for "int".  However ...
>
>(The following is a summary of most of the issues to be resolved
>for standardizing a boolean type in C9X.)
>
>IMPLEMENTATION ISSUES
>
>If you believe that a boolean type represents ``true'' and
>``false'' and that happens to be mapped into some integral type, then
>you might be interested in its implementation.  A boolean type
>can have several implementations, based upon the requirements of the
>programmer.  For example, performance attributes (fast, small,
>unoptimized)
>and addressibility (yes or no) are important implementation issues.  This
>is probably one of the reasons there are differing implementations of
>the boolean type, yet similar semantics (they all can store ``true''
>and ``false'' values).  The following are some possible implementations:
>
>        Performance     Addressible     Candidates
>        fast            yes             int (the machine's fastest type)
>        fast            no              int (the machine's fastest type)
>        unoptimized     yes             char, short, int (imp-defined)
>        unoptimized     no              bit field, char (imp-defined)
>        small           yes             char
>        small           no              bit field
>
>These issues are similar to the extended integer range proposals
>in C9X (i.e., performance attributes, addressibility) -- see the
>``Why "long long" doesn't work'' thread on "comp.std.c".  These
>implementation issues concern the native type that the boolean
>type is mapped into.
>
>PROMOTION RULES
>
>An important issue is promotion rules (another extended integer range
>issue).  There aren't problems with assigning "true" or "false",
>testing a value with "true" or "false", testing in a conditional
>statement, or converting to an arithmetic type (i.e., "false" ==> 0,
>"true" ==> 1).  But what conversions do we allow to the boolean
>type?  We could probably agree that 0 and 1, when assigned to a
>boolean type, result in "false" and "true", respectively.  But
>what about other values?  Does non-zero mean true, or the low
>order N bits == 0 (demotion to bit field, "char", or "short", or
>"int").
>
>OPERATORS
>
>What operators are allowed?  Is it only "=" and "!", or are there
>other operators (e.g., "++", "--", "&=", "|=", etc.) that are
>allowed?
>
>LIBRARY FUNCTIONS
>
>What library functions do you need?  If the boolean type is an
>abstract type, then you need conversion functions to/from text
>(e.g., format specifiers for "printf" and "scanf").
>
>BINDING
>
>How will you bind this to C?  Will there be a single boolean
>implemenation (e.g., "bool" is always equivalent to "int") or
>will there be performance tuning (e.g., "fast bool", "small bool",
>"bool:1")?  Is "bool" a "typedef", a macro, or a keyword?  Is the
>boolean type equivalent to an "enum", an integral type, or something
>else?  Is a header (e.g., "<bool.h>") required to use the type?
>
>RELATED STANDARDS
>
>WG14 is investigating a C binding to WG11's Language Independent
>Datatypes draft standard (ISO DIS 11404).  This draft standard
>includes a boolean data type.
>
>CONCLUSION
>
>The discussion in WG14 has been favorable with respect to a
>boolean type.  I think there is much agreement on the following
>points (of course, these are the easiest issues):
>
>        - "bool" will not be a keyword.  This will break much code.
>        - The header "<bool.h>" must be included to access the
>        boolean type named "bool".
>        - The identifiers "true" and "false" are the boolean values.
>        - Assignment, negation ("!"), and use in conditional statements.
>
>The following areas are fuzzy, but this is my guess of the probable
>outcome:
>
>        - Conversion of 0 and 1 to a boolean type will be well-defined.
>        - Conversion of other values will be undefined (just as
>        overflow may produce undefined behavior).
>        - The implementor will have their choice of implementing it
>        as some existing integral type in C (e.g., "char", "short",
>        "int"), an "enum", or something else.
>        - There will be a feature test macro to determine if "bool"
>        is present as a keyword.  This is a compatibility feature
>        with C++ because they (unfortunately, IMO) bound "bool" as
>        as keyword, rather the using an include file to turn on
>        the behavior (which would define the macro "bool" as whatever).
>
>The following areas are fuzzy, but I don't have a clue as to their
>outcome or existence in C9X:
>
>        - Additional format specifiers in "printf" and "scanf".
>        - Additional operators.
>        - Performance tuning.
>        - Use of "bool" in structure bit fields.
>
>The following WG14 people have been active in the discussion of the
>boolean type:
>
>        Frank Farance
>        Clive Feather
>        Francis Glassborow
>        Doug Gwyn
>        Tom Plum
>        John Washington
>
>You might contact them directly if you want to voice some of your
>concerns for C9X.
>
>-FF
>-------------------------------------------------------------------
>(``I only use AOL for reading netnews.'')
>Frank Farance, Farance Inc.
>E-mail: frank@farance.com, Telephone: +1 212 486 4700
>ISO JTC1/SC22/WG14 & ANSI X3J11 (C Programming Language) Project Editor
@@@@@@@@@@@@@@@@@@@

Thanks for the great summary...keep up the good work...

I could not help but notice that there seems to be a fair amount of
attention given to the issues that relate to C++...

...have you also looked at how the Boolean class is handled in C+@...???

BTW...are true and false identifiers or keywords...???

@@@@@@@@@@@@@@@@@@@
--
Jim Fleming            /|\      Unir Corporation       Unir Technology, Inc.
jrf@tiger.bytes.com  /  | \     One Naperville Plaza   184 Shuman Blvd. #100
%Techno Cat I       /   |  \    Naperville, IL 60563   Naperville, IL 60563
East End, Tortola  |____|___\   1-708-505-5801         1-800-222-UNIR(8647)
British Virgin Islands__|______ 1-708-305-3277 (FAX)   1-708-305-0600
                 \__/-------\__/       http:199.3.34.13 telnet: port 5555
Smooth Sailing on Cruising C+@amarans  ftp: 199.3.34.12 <-----stargate----+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\____to the end of the OuterNet_|

In article <3uukvi$t6s@metro.ucc.su.OZ.AU>, maxtal@Physics.usyd.edu.au
says...
>
>In article <KANZE.95Jul19114530@slsvhdt.lts.sel.alcatel.de>,
>James Kanze US/ESC 60/3/141 #40763 <kanze@lts.sel.alcatel.de> wrote:
>>
>>At least one of the reasons why the authors of the proposal defined ++
>>for the bool type is that it wouldn't have passed in the committee
>>otherwise.  Is that the justification you are looking for?
>
>        To clarify: ++ on bool isn't just defined.
>Its defined AND DEPREACTED. WG21 voted in and
>deprecated a feature at the same time. This was to facilitate
>a smooth transition from
>
>        #define bool int
>to
>        #if !defined(__cplusplus__)
>        #define bool int
>        #endif
>
>in a single system wide header file -- a few seconds work --
>with a minimum number of changes to most other source files.
>
>Anyone writing _new_ code using ++ on bool should be shot.
>Everyone ought to start fixing the remaining uses of ++ on
>bool because it will probably be banned in the second C++ Standard.
>
>--
>        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
@@@@@@@@@@@@@@@@@@@@@@@@@@@@

What is the "second C++ Standard"...???

--
Jim Fleming            /|\      Unir Corporation       Unir Technology, Inc.
jrf@tiger.bytes.com  /  | \     One Naperville Plaza   184 Shuman Blvd. #100
%Techno Cat I       /   |  \    Naperville, IL 60563   Naperville, IL 60563
East End, Tortola  |____|___\   1-708-505-5801         1-800-222-UNIR(8647)
British Virgin Islands__|______ 1-708-305-3277 (FAX)   1-708-305-0600
                 \__/-------\__/       http:199.3.34.13 telnet: port 5555
Smooth Sailing on Cruising C+@amarans  ftp: 199.3.34.12 <-----stargate----+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\____to the end of the OuterNet_|

FFarance (ffarance@aol.com) wrote:
: (The following is a summary of most of the issues to be resolved
: for standardizing a boolean type in C9X.)

: IMPLEMENTATION ISSUES

: If you believe that a boolean type represents ``true'' and
: ``false'' and that happens to be mapped into some integral type, then
: you might be interested in its implementation.  A boolean type
: can have several implementations, based upon the requirements of the
: programmer.  For example, performance attributes (fast, small,
: unoptimized)
: and addressibility (yes or no) are important implementation issues.  This
: is probably one of the reasons there are differing implementations of
: the boolean type, yet similar semantics (they all can store ``true''
: and ``false'' values).  The following are some possible implementations:

:  Performance Addressible Candidates
:  fast  yes  int (the machine's fastest type)
:  fast  no  int (the machine's fastest type)
:  unoptimized yes  char, short, int (imp-defined)
:  unoptimized no  bit field, char (imp-defined)
:  small  yes  char
:  small  no  bit field

: These issues are similar to the extended integer range proposals
: in C9X (i.e., performance attributes, addressibility) -- see the
: ``Why "long long" doesn't work'' thread on "comp.std.c".  These
: implementation issues concern the native type that the boolean
: type is mapped into.

Actually implementation is a possible good reason for having a bool type. The
compiler can store it in one bit. The one thing that many embeded real-time
programers keep asking me for is how to get the C compiler to support a 'bit'
sized type.

If speed is more important than size for the customers of your compiler then
one can store a bool in the the smallest addressable unit. With the tendancy
to longer and longer data sizes (see the 'long long' thread) and a move to
16 bit characters even storing bool as 8 bits when char is 16 bits can
give one a big memory saving in some uses. Assuming the hardware is still
8 bit addressable that would have no time penalty.

[ Perhaps rather than introducing 'bool' as a new keyword it should be
called 'short short char' :-)  ]

--
Stephen Baynes                              baynes@mulsoc2.serigate.philips.nl
Philips Semiconductors Ltd
Southampton                                 My views are my own.
United Kingdom

Stan Friesen (swf@elsegundoca.ncr.com) wrote:
: In article <3v65hv$64o@eco.twg.com>, lance@eco.twg.com (Lance Kibblewhite) writes:
: |>
: |> Rubbish:  Use (bool = 1) as in
: |>
: |>   if (initialized = 1)
: |>     return;
: |>   init ();

: This is not test_and_set(), this is set and branch unconditionally!

: The function the prior poster gave is the closest I have seen,
: and even it has the disagvantage that it cannot be easily optimized
: to the hardware test-and-set instruction.  The post-increment *can*
: be so optimized - almost trivially (by setting the translation table to
: emit the hardware t&s instruction as the translation).

I would expect that that special test-and-set instructions are quite rare
(except perhaps ones specially provided to implement semaphores and those may
have undesirable side effects such as cache flushing). If you don't have a
test and set instructions you are more likly to make the performance worse by
using post++ rather than testing and seting separately. For example post++
requires that a value is written back to the variable even when it is already
set. This takes time and reduces the options available to the compiler for its
data-flow analysis. If you test and set separately then the variable only
needs to be written if it is set. Also post++ may require two registers to
implement rather than one.

--
Stephen Baynes                              baynes@mulsoc2.serigate.philips.nl
Philips Semiconductors Ltd
Southampton                                 My views are my own.
United Kingdom

In article <DCKKqM.2Ap@ukpsshp1.serigate.philips.nl>, baynes@ukpsshp1.serigate.philips.nl (Stephen Baynes) writes
+ ....
+ [ Perhaps rather than introducing 'bool' as a new keyword it should be
+ called 'short short char' :-)  ]

Or 'short short short int'??

jim.fleming@bytes.com (Jim Fleming) writes:

>[huge amount of quoted article then a few lines of response]

Fleming, you're an absolute moron. You've been around long enough to
know how to use a newsreader and trim articles, yet you've posted
about half a dozen today that are all the same. I've tried to give
you the benefit of the doubt until now, but this takes the cake.

And don't waste your time giving us some bilge about your outernet.
You're inconsiderate. That's all there is to it.

If you ever had any credibility, you've lost it.

--

Ron House.         USQ                   | A nonviolent diet is the
(house@usq.edu.au) Toowoomba, Australia. | foundation for a nonviolent world.

In article <MATT.95Jul26220946@godzilla.EECS.Berkeley.EDU>,
matt@godzilla.EECS.Berkeley.EDU (Matt Austern) wrote:

>Most authors of C++ libraries, though, disagree with us: I have yet to
>see any large C++ library that doesn't define a boolean type.  This
>presents a serious interoperability problem, since these definitions
>often tend to clash.

Unfortunately, this isn't limited to C++ libraries.  I'm sure many
here have seen or written their share of

    #define Boolean int
    typedef int bool;
    typedef enum { FALSE, TRUE} LOGICAL;
    #define BOOLEAN char  /* etc. */

Mix and match a few header files from different vendors and the sparks
can start flying.

This leads to one of the grey areas in namespace: where does the
third-party library vendor place his external and included symbols?
I groan whenever I find libraries functions with generic names such as
reset(), startup(), error(), etc.

>The situation right now in C++ is that everyone is using boolean types
>but everyone is doing it in slightly different and slightly
>incompatible ways.

Sounds familiar.

>This is precisely the sort of situation that
>standards are supposed to address, which is why adding bool to the
>C++ standard was a good decision.

That's the best argument I have heard yet.

Thad

In <DC4HDq.KDL@research.att.com>, Andrew Koenig (ark@research.att.com) wrote
: In article <1995Jul22.022031.10937@sq.sq.com> msb@sq.sq.com (Mark Brader) writes:

: > If we're talking about C (it's hard to tell, since this entire thread
: > is cross-posted), I'd say that there's absolutely no justification for
: > adding a "bool type" to the language in the first place, and good reason
: > (as covered in the comp.lang.c FAQ list) not to do so.

: That may be true for C, but C doesn't have overloading.
: With overloaded functions, the case for bool being a
: separate type is much stronger.

This is true, but one of the great strengths of C++ is supposed to be
it wonderful type definition facilities.  If it is necessary to build
as simple a type as this into the language, the whole thing begins to
look pretty silly.

--
Peter Curran                                        pcurran@isgtec.com
ISG Technologies, Inc                              (905) 672-2100 X315
6509 Airport Road,        http://www.isgtec.com     Fax (905) 672-2307
Mississauga, Ontario, Canada                   Usual disclaimers apply

In article <3va828$i8@gabi.gabi-soft.fr>, kanze@gabi-soft.fr (J. Kanze) writes
> So how come I see so much code with things like:
>
>  if ( ! strcmp( .. ) ) ...
>
> I know that strcmp does not return a boolean value.  That is precisely
> why I chose it as an example: bool and int are two fundamentally
> different things, and C confuses them (and causes not a few programmers
> to confuse them, too).


C can't confuse them, for there is no 'bool' in C.

No amount of repetition that "if" and "while" ... go onlie one of two ways
shows that there is such a type, not even hidden in the shadows.  The same
reazoning applys to "switch", or Fortran s arithmetic "if".

lance@eco.twg.com (Lance Kibblewhite) wrote:

<whoops>

Ok, Ok, Shoot me.



-- Lance.

Lance Kibblewhite (lance@eco.twg.com) wrote:
: jason@cygnus.com (Jason Merrill) wrote:

: >>>>>> John Max Skaller <maxtal@Physics.usyd.edu.au> writes:

: >> Anyone writing _new_ code using ++ on bool should be shot.

: >As someone else pointed out, bool++ is a nice shorthand for test-and-set.
: >The only alternative is much more verbose:

: >inline bool test_and_set (bool& flag)
: >{
: >  bool b = flag; flag = true; return b;
: >}

: >...

: >  if (test_and_set (initialized))
: >    return;
: >  init ();

: >...

: Rubbish:  Use (bool = 1) as in

:   if (initialized = 1)
:     return;
:   init ();

To get what the original poster wanted one needs:
   if( initialized )
        return;
   initialized = 1;
   init();

--
Stephen Baynes                              baynes@mulsoc2.serigate.philips.nl
Philips Semiconductors Ltd
Southampton                                 My views are my own.
United Kingdom

In article <3v65hv$64o@eco.twg.com>, lance@eco.twg.com (Lance Kibblewhite) writes:
|>
|> Rubbish:  Use (bool = 1) as in
|>
|>   if (initialized = 1)
|>     return;
|>   init ();

This is not test_and_set(), this is set and branch unconditionally!

The function the prior poster gave is the closest I have seen,
and even it has the disagvantage that it cannot be easily optimized
to the hardware test-and-set instruction.  The post-increment *can*
be so optimized - almost trivially (by setting the translation table to
emit the hardware t&s instruction as the translation).

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

The peace of God be with you.

In article <KANZE.95Jul24140444@slsvhdt.lts.sel.alcatel.de>,
James Kanze US/ESC 60/3/141 #40763 <kanze@lts.sel.alcatel.de> wrote
: Instead, the programmer must depend on a
: variety of sometimes confusing implicit type conversions.  (Quick:
: does strcmp return true or false when the strings match.)

In article <3v2rs8$hdo@deneb.tm.informatik.uni-frankfurt.de>, Anselm Lingnau <lingnau@tm.informatik.uni-frankfurt.de> writes
: strcmp() doesn't return a boolean result in disguise -- it returns an
: arithmetic result that can assume a negative, zero or positive value
: depending on whether the first argument is lexicographically less, equal
: to or greater than the second. Therefore it has no place in this
: discussion at all. It certainly serves as a nice example for the
: misconceptions that surround the issue, though.
: ....

This exactlie reflects my point, that there is no special plase
in programming for a two-stated type.  It seldom is thus needed,
certainlie not enough for a new type & kieword.

In article <KANZE.95Jul26122240@slsvhdt.lts.sel.alcatel.de>, kanze@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763) writes
- ....
- My point is precisely that C has, at least implicitly, a built-in
- boolean type.  You cannot have `if' or `while' otherwise.  (Actually,
- you can.  Fortran has a three way `if':-).)
The first claim is sheer invention, and with your referring to Fortran s
famous three-wai "if" you reveal it.  C no more has a bilt-in "boolean"
(two-valued) type than Fortran has a three-valued.

- ....
- 1. You occasionally loose the fun of firing up the debugger, since the
- compiler is catching a certain class of errors which otherwise make it
- out into the executable.
-
- 2. It becomes slightly more difficult to write unreadable code, since
- when you want a predicate, you are obliged to write what you want,
- rather than have all sorts of hidden conversions taking place.
Insofar as this is tru, it is not an argument for declaring such variables,
except that on rare occazions a programmer wants to store such a state in one.
It seldom happens.

- ....

In article <3v73r0$muv@caip.rutgers.edu> halasz@caip.rutgers.edu writes:

> This exactlie reflects my point, that there is no special plase
> in programming for a two-stated type.  It seldom is thus needed,
> certainlie not enough for a new type & kieword.

I tend to agree, actually: it would have been nice if C had had a
boolean type from the very beginning, but it doesn't take much effort
to get used to the idea that truth values are represented by integers.

Most authors of C++ libraries, though, disagree with us: I have yet to
see any large C++ library that doesn't define a boolean type.  This
presents a serious interoperability problem, since these definitions
often tend to clash.

The situation right now in C++ is that everyone is using boolean types
but everyone is doing it in slightly different and slightly
incompatible ways.  This is precisely the sort of situation that
standards are supposed to address, which is why adding bool to the
C++ standard was a good decision.
--
  Matt Austern                             He showed his lower teeth.  "We
  matt@physics.berkeley.edu                all have flaws," he said, "and
  http://dogbert.lbl.gov/~matt             mine is being wicked."

JdeBP@jba.co.uk (Jonathan de Boyne Pollard) writes:

>Mike Ball (ball@Eng.Sun.COM) wrote:
>: The issue is that there is a lot of existing C++ code that uses the idiom,
>: and we really don't want to cause any more pain than necessary.
>
>Incidentally, it's time for another reminder.
>
>There are *no* existing idioms for `bool'.  People do *not* write
>
>       bool p = false ;
>       ..
>       ..
>       if ( blah ) ++p ;

You are quite simply wrong.  That sort of code does exist.
It's usually preceded by

 #include "some_header_file.h"

which contains

 typedef int bool;
 #define false 0
 #define true 1

Of course, they will often have spelt `false' and `true' as `FALSE' and `TRUE,
and they may also have used a different spelling for `bool'.
But even then, the same difficulties apply.

--
Fergus Henderson              | Designing grand concepts is fun;
fjh@cs.mu.oz.au               | finding nitty little bugs is just work.
http://www.cs.mu.oz.au/~fjh   | -- Brooks, in "The Mythical Man-Month".
PGP key fingerprint: 00 D7 A2 27 65 09 B6 AC  8B 3E 0F 01 E7 5D C4 3F

In article <KANZE.95Jul26122240@slsvhdt.lts.sel.alcatel.de>,
James Kanze US/ESC 60/3/141 #40763 <kanze@lts.sel.alcatel.de> wrote:

> The result of a lack of an explicit boolean type results in precisely
> the ambiguities you are talking about.  How often does one see:
>
>  if ( strcmp( s1 , s2 ) )  /*  strings are not ==   */
>  if ( p )                  /*  pointer is not NULL  */
>  if ( *p )                 /*  not at end of string */
>
> Such code has become so prevalent in C that some people actually argue
> that it is good, or readable.

I can see a problem with the strcmp(), which is why I use something like

 #define STR_EQ(a, b) (strcmp((a), (b)) == 0)

But this has nothing to do with the boolean type issue. As far as the
`hacky' implicit comparison to 0 in the last two examples go, as a C
programmer with some experience I find their meaning completely obvious,
though I don't use them in code that I write (well, not often, anyway).

> My point is precisely that C has, at least implicitly, a built-in
> boolean type.  You cannot have `if' or `while' otherwise.

I don't buy that. The zero/non-zero convention as used by conditionals
doesn't make `int' a `built-in boolean type'. C doesn't have a built-in
character type either (the way Pascal does), and that doesn't keep us
from using `char' to do string operations. Anybody want to argue for
a built-in character type that's not an integer type?

> (Seriously, the problem of breaking existing code means that it is
> impossible to adapt anything more than a compromize solution.)

Exactly. So all you end up with is a gratuitiously complex language
definition. It would be more worthwhile to fix your compiler to emit
a warning if you use an implicit comparison to 0, rather than force
a built-in boolean type down everybody's throats.

Anselm
--
Anselm Lingnau ......................... lingnau@tm.informatik.uni-frankfurt.de
Programming today is a race between software engineers striving to build bigger
and better idiot-proof programs, and the Universe trying to produce bigger and
better idiots.  So far, the Universe is winning.                  --- Rich Cook

Trebor A. Rude (trebor@en.ecn.purdue.edu) wrote:

|> In Article<KANZE.95Jul24140444@slsvhdt.lts.sel.alcatel.de>,
|> <kanze@lts.sel.alcatel.de> write:

|> > variety of sometimes confusing implicit type conversions.  (Quick:
|> > does strcmp return true or false when the strings match.)  The

|>  Bad example, strcmp() makes a three way decision.  Lexiographically
|> less than, equal to, or lexiographically greater than.  And strcmp() returns
|> FALSE when the strings match. :)

So how come I see so much code with things like:

 if ( ! strcmp( .. ) ) ...

I know that strcmp does not return a boolean value.  That is precisely
why I chose it as an example: bool and int are two fundamentally
different things, and C confuses them (and causes not a few programmers
to confuse them, too).
--
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils en informatique industrielle--
                             --Beratung in industrieller Datenverarbeitung

Lance Kibblewhite (lance@eco.twg.com) wrote:
|> jason@cygnus.com (Jason Merrill) wrote:

|> >>>>>> John Max Skaller <maxtal@Physics.usyd.edu.au> writes:

|> >> Anyone writing _new_ code using ++ on bool should be shot.

|> >As someone else pointed out, bool++ is a nice shorthand for test-and-set.
|> >The only alternative is much more verbose:

|> >inline bool test_and_set (bool& flag)
|> >{
|> >  bool b = flag; flag = true; return b;
|> >}

|> >...

|> >  if (test_and_set (initialized))
|> >    return;
|> >  init ();

|> >...

|> Rubbish:  Use (bool = 1) as in

|>   if (initialized = 1)
|>     return;
|>   init ();

Bad example.  A good compiler will optimize away all of the code
following the return.  The expression is always true, regardless of the
previous value of initialized.

As for test and set: this operation is normally used to implement
semaphores and such.  The standard does not pretend to address the
issues of multi-threaded code, and so should not consider the
possibilities of test and set.  (Note that for test and set to be
useful, it is necessary for it to be atomic.  This is definitely not
guaranteed by the standard.)
--
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils en informatique industrielle--
                             --Beratung in industrieller Datenverarbeitung

Matt Austern (matt@godzilla.EECS.Berkeley.EDU) wrote:
|> In article <3v73r0$muv@caip.rutgers.edu> halasz@caip.rutgers.edu writes:

|> > This exactlie reflects my point, that there is no special plase
|> > in programming for a two-stated type.  It seldom is thus needed,
|> > certainlie not enough for a new type & kieword.

|> I tend to agree, actually: it would have been nice if C had had a
|> boolean type from the very beginning, but it doesn't take much effort
|> to get used to the idea that truth values are represented by integers.

And pointers.  And floating point values.

I often use AWK; it is not difficult to get used to the idea that truth
values (and everything else) is represented by a string.  (One of the
nicest things about AWK is that even array indexes are strings.)

I accept (willing) the lack of type checking in AWK because I get
something very important in return: simplicity.  The lack of types means
no declarations, etc., and leads to much shorter and simpler programs.

This simplicity is not without drawbacks, and it wouldn't occur to me to
use AWK for a large application (say >10000 LOC).  Once programs reach a
certain size, I need, or at least want, help from the compiler to keep
things straight.  For me, at least, a major requirement for a language
to be used on large applications is strict static type checking: the
stricter the better.  If two objects have a different set of values
and/or a different set of legal operations, I want them to have
different types, so that the compiler can tell me if I accidentally use
one when I want the other.
--
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils en informatique industrielle--
                             --Beratung in industrieller Datenverarbeitung

In article <3uukvi$t6s@metro.ucc.su.OZ.AU> maxtal@Physics.usyd.edu.au
(John Max Skaller) writes:

|> Anyone writing _new_ code using ++ on bool should be shot.
|> Everyone ought to start fixing the remaining uses of ++ on
|> bool because it will probably be banned in the second C++ Standard.

Like arithmetic if in Fortran:-)?
--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                              -- Beratung in industrieller Datenverarbeitung

> > > There's absolutely no justification in adding all sorts of stupid and
> > > non-obvious quirks to the bool type (such as ... ++ ...)
> >
> > If we're talking about C ... I'd say that there's absolutely no
> > justification for adding a "bool type" to the language ...
>
> A boolean type isn't really required in C, assuming you believe that
> "bool" is just another name for "int".

No, that's not what I'm saying.  I'm saying that there is no justification
for adding to the language a type specific to boolean values, when such
values can already be manipulated in any of several types.  (One of which
is indeed int.)  Dennis Ritchie got it right.

>  However ...
>
> (The following is a summary of most of the issues to be resolved
> for standardizing a boolean type in C9X.)

In short, it's a statement that there is no natural way to add the type
to the language.  It is needless.  Be off with it.

(I've retained the cross-posting, but I'm talking only about C here.)
--
Mark Brader, msb@sq.com          "Not looking like Pascal is not
SoftQuad Inc., Toronto            a language deficiency!"    -- Doug Gwyn

This article is in the public domain.

In Article<KANZE.95Jul24140444@slsvhdt.lts.sel.alcatel.de>,
<kanze@lts.sel.alcatel.de> write:

> variety of sometimes confusing implicit type conversions.  (Quick:
> does strcmp return true or false when the strings match.)  The

 Bad example, strcmp() makes a three way decision.  Lexiographically
less than, equal to, or lexiographically greater than.  And strcmp() returns
FALSE when the strings match. :)

> --
> James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
> GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
> Conseils en informatique industrielle --
>                               -- Beratung in industrieller Datenverarbeitung

Trebor A. Rude
trebor@en.ecn.purdue.edu

In article <1995Jul26.030356.21528@sq.sq.com> msb@sq.sq.com (Mark Brader) writes:

> No, that's not what I'm saying.  I'm saying that there is no justification
> for adding to the language a type specific to boolean values, when such
> values can already be manipulated in any of several types.  (One of which
> is indeed int.)  Dennis Ritchie got it right.

The justification is:

 1. Unless bool is a separate type, there's no way to overload on it.

 2. It can't be a user-defined type because there's no way
    for users to define the type of expressions like 3<4.

Because C doesn't have overloading, this is much less of an issue for
C than it is for C++.
--
    --Andrew Koenig
      ark@research.att.com

In article <3v2rs8$hdo@deneb.tm.informatik.uni-frankfurt.de> Anselm
Lingnau <lingnau@tm.informatik.uni-frankfurt.de> writes:

|> In article <KANZE.95Jul24140444@slsvhdt.lts.sel.alcatel.de>,
|> James Kanze US/ESC 60/3/141 #40763 <kanze@lts.sel.alcatel.de> wrote:

|> > Instead, the programmer must depend on a
|> > variety of sometimes confusing implicit type conversions.  (Quick:
|> > does strcmp return true or false when the strings match.)

|> strcmp() doesn't return a boolean result in disguise -- it returns an
|> arithmetic result that can assume a negative, zero or positive value
|> depending on whether the first argument is lexicographically less, equal
|> to or greater than the second. Therefore it has no place in this
|> discussion at all. It certainly serves as a nice example for the
|> misconceptions that surround the issue, though.

It certainly does.  I am perfectly aware of what strcmp returns.  It
does not return a bool, even disguised as an int.

The result of a lack of an explicit boolean type results in precisely
the ambiguities you are talking about.  How often does one see:

 if ( strcmp( s1 , s2 ) )  /*  strings are not ==   */
 if ( p )                  /*  pointer is not NULL  */
 if ( *p )                 /*  not at end of string */

Such code has become so prevalent in C that some people actually argue
that it is good, or readable.  With a real boolean type, the error is
immediately obvious (pointers, char's and the results of strcmp are
*not* logical yes or no values).  The programmer would be required to
write what he means rather than depending on a hacky implicit
conversion:

 if ( strcmp( s1 , s2 ) != 0 )
 if ( p != NULL )
 if ( *p != '\0' )

|> IMHO C needs a built-in boolean type just about as badly as a fish needs
|> wheels.

My point is precisely that C has, at least implicitly, a built-in
boolean type.  You cannot have `if' or `while' otherwise.  (Actually,
you can.  Fortran has a three way `if':-).)

I can only think of two arguments against a real boolean type:

1. You occasionally loose the fun of firing up the debugger, since the
compiler is catching a certain class of errors which otherwise make it
out into the executable.

2. It becomes slightly more difficult to write unreadable code, since
when you want a predicate, you are obliged to write what you want,
rather than have all sorts of hidden conversions taking place.

(Seriously, the problem of breaking existing code means that it is
impossible to adapt anything more than a compromize solution.)
--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                              -- Beratung in industrieller Datenverarbeitung

In article <KANZE.95Jul24140444@slsvhdt.lts.sel.alcatel.de>
kanze@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763) writes:

[snip]

> Actually, I would argue that C/C++ have always had a boolean type.
> After all, there are definitely situations where the compiler
> generates code which makes a yes/no or true/false decision, which is
> the fundamental characteristic of a boolean type.
>
> The ``problem'' with C/C++ is that there is (or was) no way for the
> user to define a variable with such a type, or even write an
> expression with such a type.  Instead, the programmer must depend on a
> variety of sometimes confusing implicit type conversions.  (Quick:
> does strcmp return true or false when the strings match.)  The
> presence of such conversions (and the supposed absense of a boolean
> type) has in turn lead to a number of questionable idioms: `if ( p )',
> `while ( *p )', etc.  While professional programmers quickly learn to
> understand them in other's code, and avoid them in their own, such
> idioms *do* cause confusion, particularly with less skilled
> programmers.

I agree. If C++ was a new language defined from scratch, having a built-in
bool type would make a lot of sense. This is not the case, of course, and
as a result of that, the desire to accomodate existing practice has lead
us to a bool type that's so cluttered I think we're better off without it.

- Wil

markus.freericks@n8sbridge.com (Markus Freericks) writes:

>(*) Maybe <boolvar>++ could be introduced as a "deprecated" feature?

It *is* as a deprecated feature!

--
Fergus Henderson              | Designing grand concepts is fun;
fjh@cs.mu.oz.au               | finding nitty little bugs is just work.
http://www.cs.mu.oz.au/~fjh   | -- Brooks, in "The Mythical Man-Month".
PGP key fingerprint: 00 D7 A2 27 65 09 B6 AC  8B 3E 0F 01 E7 5D C4 3F

In article <KANZE.95Jul24140444@slsvhdt.lts.sel.alcatel.de>,
James Kanze US/ESC 60/3/141 #40763 <kanze@lts.sel.alcatel.de> wrote:

> Instead, the programmer must depend on a
> variety of sometimes confusing implicit type conversions.  (Quick:
> does strcmp return true or false when the strings match.)

strcmp() doesn't return a boolean result in disguise -- it returns an
arithmetic result that can assume a negative, zero or positive value
depending on whether the first argument is lexicographically less, equal
to or greater than the second. Therefore it has no place in this
discussion at all. It certainly serves as a nice example for the
misconceptions that surround the issue, though.

IMHO C needs a built-in boolean type just about as badly as a fish needs
wheels. I am appalled at the way people try to make a useful little
language like C into an abomination straight out of Hell like C++. If
you want built-in booleans, operator overloading, polymorphism and
classes, you know where to find them :^)

Anselm
--
Anselm Lingnau ......................... lingnau@tm.informatik.uni-frankfurt.de
After the game, the king and pawn go into the same box.     --- Italian proverb

> From: jason@cygnus.com (Jason Merrill)
>
> If so, conversion of values other than 1 and 0 must be defined.  If
people
> rely on, say, integer 42 being treated as 'true' in C89, it must still
be
> treated as 'true' in C9X, or everything will break.

There is *definitely* no motivation to change this behavior.

-FF
-------------------------------------------------------------------
(``I only use AOL for reading netnews.'')
Frank Farance, Farance Inc.
E-mail: frank@farance.com, Telephone: +1 212 486 4700
ISO JTC1/SC22/WG14 & ANSI X3J11 (C Programming Language) Project Editor

In article <DByKnM.L5L@aisb.ed.ac.uk>,
Andrew Fitzgibbon <andrewfg@ed.ac.uk> wrote:
>
>< Many of the uglier aspects of C++ would have disappeared long ago if we
>< actually had the option of cutting the ties to C.
>
>Many of the uglier aspects of C++ are not *in* C :-).

 True. Much of the high power functionality isn't available
in C either.

>Noone wants to *cut* the ties to C

 Speak for yourself. I'd LOVE to get rid of any requirement
for C compatibility. But it isn't an option. C compatibility is what
makes C++ popular.

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,
        81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21
        NSW 2037, AUSTRALIA     Phone: 61-2-566-2189

In article <1995Jul22.022031.10937@sq.sq.com> msb@sq.sq.com (Mark Brader) writes:

> If we're talking about C (it's hard to tell, since this entire thread
> is cross-posted), I'd say that there's absolutely no justification for
> adding a "bool type" to the language in the first place, and good reason
> (as covered in the comp.lang.c FAQ list) not to do so.

That may be true for C, but C doesn't have overloading.
With overloaded functions, the case for bool being a
separate type is much stronger.
--
    --Andrew Koenig
      ark@research.att.com

> From: msb@sq.sq.com (Mark Brader)
>
> > There's absolutely no justification in adding all sorts of stupid and
> > non-obvious quirks to the bool type (such as the example under
discussion
> > of allowing the ++ operator) ...
>
> If we're talking about C (it's hard to tell, since this entire thread
> is cross-posted), I'd say that there's absolutely no justification for
> adding a "bool type" to the language in the first place, and good reason
> (as covered in the comp.lang.c FAQ list) not to do so.

A boolean type isn't really required in C, assuming you believe that
"bool" is just another name for "int".  However ...

(The following is a summary of most of the issues to be resolved
for standardizing a boolean type in C9X.)

IMPLEMENTATION ISSUES

If you believe that a boolean type represents ``true'' and
``false'' and that happens to be mapped into some integral type, then
you might be interested in its implementation.  A boolean type
can have several implementations, based upon the requirements of the
programmer.  For example, performance attributes (fast, small,
unoptimized)
and addressibility (yes or no) are important implementation issues.  This
is probably one of the reasons there are differing implementations of
the boolean type, yet similar semantics (they all can store ``true''
and ``false'' values).  The following are some possible implementations:

 Performance Addressible Candidates
 fast  yes  int (the machine's fastest type)
 fast  no  int (the machine's fastest type)
 unoptimized yes  char, short, int (imp-defined)
 unoptimized no  bit field, char (imp-defined)
 small  yes  char
 small  no  bit field

These issues are similar to the extended integer range proposals
in C9X (i.e., performance attributes, addressibility) -- see the
``Why "long long" doesn't work'' thread on "comp.std.c".  These
implementation issues concern the native type that the boolean
type is mapped into.

PROMOTION RULES

An important issue is promotion rules (another extended integer range
issue).  There aren't problems with assigning "true" or "false",
testing a value with "true" or "false", testing in a conditional
statement, or converting to an arithmetic type (i.e., "false" ==> 0,
"true" ==> 1).  But what conversions do we allow to the boolean
type?  We could probably agree that 0 and 1, when assigned to a
boolean type, result in "false" and "true", respectively.  But
what about other values?  Does non-zero mean true, or the low
order N bits == 0 (demotion to bit field, "char", or "short", or
"int").

OPERATORS

What operators are allowed?  Is it only "=" and "!", or are there
other operators (e.g., "++", "--", "&=", "|=", etc.) that are
allowed?

LIBRARY FUNCTIONS

What library functions do you need?  If the boolean type is an
abstract type, then you need conversion functions to/from text
(e.g., format specifiers for "printf" and "scanf").

BINDING

How will you bind this to C?  Will there be a single boolean
implemenation (e.g., "bool" is always equivalent to "int") or
will there be performance tuning (e.g., "fast bool", "small bool",
"bool:1")?  Is "bool" a "typedef", a macro, or a keyword?  Is the
boolean type equivalent to an "enum", an integral type, or something
else?  Is a header (e.g., "<bool.h>") required to use the type?

RELATED STANDARDS

WG14 is investigating a C binding to WG11's Language Independent
Datatypes draft standard (ISO DIS 11404).  This draft standard
includes a boolean data type.

CONCLUSION

The discussion in WG14 has been favorable with respect to a
boolean type.  I think there is much agreement on the following
points (of course, these are the easiest issues):

 - "bool" will not be a keyword.  This will break much code.
 - The header "<bool.h>" must be included to access the
 boolean type named "bool".
 - The identifiers "true" and "false" are the boolean values.
 - Assignment, negation ("!"), and use in conditional statements.

The following areas are fuzzy, but this is my guess of the probable
outcome:

 - Conversion of 0 and 1 to a boolean type will be well-defined.
 - Conversion of other values will be undefined (just as
 overflow may produce undefined behavior).
 - The implementor will have their choice of implementing it
 as some existing integral type in C (e.g., "char", "short",
 "int"), an "enum", or something else.
 - There will be a feature test macro to determine if "bool"
 is present as a keyword.  This is a compatibility feature
 with C++ because they (unfortunately, IMO) bound "bool" as
 as keyword, rather the using an include file to turn on
 the behavior (which would define the macro "bool" as whatever).

The following areas are fuzzy, but I don't have a clue as to their
outcome or existence in C9X:

 - Additional format specifiers in "printf" and "scanf".
 - Additional operators.
 - Performance tuning.
 - Use of "bool" in structure bit fields.

The following WG14 people have been active in the discussion of the
boolean type:

 Frank Farance
 Clive Feather
 Francis Glassborow
 Doug Gwyn
 Tom Plum
 John Washington

You might contact them directly if you want to voice some of your
concerns for C9X.

-FF
-------------------------------------------------------------------
(``I only use AOL for reading netnews.'')
Frank Farance, Farance Inc.
E-mail: frank@farance.com, Telephone: +1 212 486 4700
ISO JTC1/SC22/WG14 & ANSI X3J11 (C Programming Language) Project Editor

Andrew Koenig (ark@research.att.com) wrote:
: In article <1995Jul22.022031.10937@sq.sq.com> msb@sq.sq.com (Mark
: Brader) writes:

: > If we're talking about C (it's hard to tell, since this entire thread
: > is cross-posted), I'd say that there's absolutely no justification for
: > adding a "bool type" to the language in the first place, and good reason
: > (as covered in the comp.lang.c FAQ list) not to do so.

: That may be true for C, but C doesn't have overloading.
: With overloaded functions, the case for bool being a
: separate type is much stronger.

Possibly a case could be made for a general mechanism to added
overloadable aliases for built-in types to the system.

e.g.

 overloadable typedef double velocity;
 ostream &operator <<(ostream &os, velocity v)
 {
  return os << static_cast<double>(v) << "m/s";
 }

--
        Tony Cook - tony@online.tmx.com.au
                    100237.3425@compuserve.com

In article <KANZE.95Jul19114530@slsvhdt.lts.sel.alcatel.de>,
James Kanze US/ESC 60/3/141 #40763 <kanze@lts.sel.alcatel.de> wrote:
>
>At least one of the reasons why the authors of the proposal defined ++
>for the bool type is that it wouldn't have passed in the committee
>otherwise.  Is that the justification you are looking for?

 To clarify: ++ on bool isn't just defined.
Its defined AND DEPREACTED. WG21 voted in and
deprecated a feature at the same time. This was to facilitate
a smooth transition from

 #define bool int
to
 #if !defined(__cplusplus__)
 #define bool int
 #endif

in a single system wide header file -- a few seconds work --
with a minimum number of changes to most other source files.

Anyone writing _new_ code using ++ on bool should be shot.
Everyone ought to start fixing the remaining uses of ++ on
bool because it will probably be banned in the second C++ Standard.

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,
        81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21
        NSW 2037, AUSTRALIA     Phone: 61-2-566-2189

>>>>> FFarance  <ffarance@aol.com> writes:

> CONCLUSION

> The discussion in WG14 has been favorable with respect to a
> boolean type.  I think there is much agreement on the following
> points (of course, these are the easiest issues):

>  - "bool" will not be a keyword.  This will break much code.
>  - The header "<bool.h>" must be included to access the
>  boolean type named "bool".
>  - The identifiers "true" and "false" are the boolean values.
>  - Assignment, negation ("!"), and use in conditional statements.

> The following areas are fuzzy, but this is my guess of the probable
> outcome:

>  - Conversion of 0 and 1 to a boolean type will be well-defined.
>  - Conversion of other values will be undefined (just as
>  overflow may produce undefined behavior).

Will conditions take expressions of type bool?  How about ||, &&, ?: and ! ?
If so, conversion of values other than 1 and 0 must be defined.  In any
case, it seems silly to introduce a discrepancy between conversions to bool
and parts of the language that already take boolean values; if || treats
integer 42 as 'true', it should convert to boolean 'true'.

Jason

In article <DC06rH.4xt@ukpsshp1.serigate.philips.nl>
baynes@ukpsshp1.serigate.philips.nl (Stephen Baynes) writes:

|> Andrew Koenig (ark@research.att.com) wrote:

|> : Of course there is: that's what the committee voted for.

|> : The main advantage of a democratic process is that the result is
|> : acceptable to a large number of people.  That is also the
|> : main disadvantage.
|> : --

|> I hardly call the committee a democracy - they are not even elected. Even if
|> they were representative-democracy is not as good as participative-democracy
|> in producing a result acceptable to a large number of people.

But the committee is actually a participative democracy.  Anyone who
wants can join the committee and vote.

(Actually, there is a restriction: if your employer is a member, you
may not join.  This is to prevent ballot box stuffing.)
--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                              -- Beratung in industrieller Datenverarbeitung

In article <1995Jul20.110506.1372@ittpub> wil@ittpub.nl (Wil Evers)
writes:

|> In article <KANZE.95Jul19114530@slsvhdt.lts.sel.alcatel.de>
|> kanze@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763) writes:

|> > At least one of the reasons why the authors of the proposal defined ++
|> > for the bool type is that it wouldn't have passed in the committee
|> > otherwise.

|> How interesting! If the advocates of the built-in bool would have done the
|> right thing, which is not to define ++ on it, than the committee would
|> have done the right thing too, which is not to have the built-in bool at
|> all. The built-in bool is just an unfortunate accident!

Actually, I would argue that C/C++ have always had a boolean type.
After all, there are definitely situations where the compiler
generates code which makes a yes/no or true/false decision, which is
the fundamental characteristic of a boolean type.

The ``problem'' with C/C++ is that there is (or was) no way for the
user to define a variable with such a type, or even write an
expression with such a type.  Instead, the programmer must depend on a
variety of sometimes confusing implicit type conversions.  (Quick:
does strcmp return true or false when the strings match.)  The
presence of such conversions (and the supposed absense of a boolean
type) has in turn lead to a number of questionable idioms: `if ( p )',
`while ( *p )', etc.  While professional programmers quickly learn to
understand them in other's code, and avoid them in their own, such
idioms *do* cause confusion, particularly with less skilled
programmers.
--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                              -- Beratung in industrieller Datenverarbeitung

> From: jason@cygnus.com (Jason Merrill)
> ...
> > CONCLUSION
>
> > The discussion in WG14 has been favorable with respect to a
> > boolean type.  I think there is much agreement on the following
> > points (of course, these are the easiest issues):
>
> >  - "bool" will not be a keyword.  This will break much code.
> >  - The header "<bool.h>" must be included to access the
> >  boolean type named "bool".
> >  - The identifiers "true" and "false" are the boolean values.
> >  - Assignment, negation ("!"), and use in conditional statements.
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

> ...
> Will conditions take expressions of type bool?  How about ||, &&, ?: and
! ?

You probably missed the sentence I highlighted above in my original
posting.  Yes, they can be used in conditions (e.g., "if", "switch",
"for", "while", "||", "&&", "?:", "!", "==").

-FF
-------------------------------------------------------------------
(``I only use AOL for reading netnews.'')
Frank Farance, Farance Inc.
E-mail: frank@farance.com, Telephone: +1 212 486 4700
ISO JTC1/SC22/WG14 & ANSI X3J11 (C Programming Language) Project Editor

In article <KANZE.95Jul24145818@slsvhdt.lts.sel.alcatel.de>, kanze@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763) writes
> Are you claiming that there is no place in C where a predicate is
> used.  That `if' or `while' don't make a binary decision.
>
> C in fact has a boolean type; it just keeps it a secret (and thus
> forces the programmer to depend on implicit conversions).


Yes, "if" and "while" make a binarie decizion--so what?
Fortran had a three-valud type becauz it had arithmetic "if"?
C has no boolean type.

In article <KANZE.95Jul24140444@slsvhdt.lts.sel.alcatel.de>, kanze@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763) writes
> Actually, I would argue that C/C++ have always had a boolean type.
> After all, there are definitely situations where the compiler
> generates code which makes a yes/no or true/false decision, which
> is the fundamental characteristic of a boolean type.

In real code this almost nevver is found except in conditional
expressions.  Therefore there is no need for a variable, for the
condition almost nevver is stord.  Stord conditions often hav more
than twain states, even as "strcmp" returns (Happens I hav longd for
Fortran s three-way "if", although not in its original "goto"ish form).

In article <1995Jul22.022031.10937@sq.sq.com> msb@sq.sq.com (Mark
Brader) writes:

|> > There's absolutely no justification in adding all sorts of stupid and
|> > non-obvious quirks to the bool type (such as the example under discussion
|> > of allowing the ++ operator) ...

|> If we're talking about C (it's hard to tell, since this entire thread
|> is cross-posted), I'd say that there's absolutely no justification for
|> adding a "bool type" to the language in the first place, and good reason
|> (as covered in the comp.lang.c FAQ list) not to do so.

Are you claiming that there is no place in C where a predicate is
used.  That `if' or `while' don't make a binary decision.

C in fact has a boolean type; it just keeps it a secret (and thus
forces the programmer to depend on implicit conversions).
--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                              -- Beratung in industrieller Datenverarbeitung

>>>>> John Max Skaller <maxtal@Physics.usyd.edu.au> writes:

> Anyone writing _new_ code using ++ on bool should be shot.

As someone else pointed out, bool++ is a nice shorthand for test-and-set.
The only alternative is much more verbose:

inline bool test_and_set (bool& flag)
{
  bool b = flag; flag = true; return b;
}

...

  if (test_and_set (initialized))
    return;
  init ();

...

Perhaps they should only be chastized.  :)

Jason

Andrew Koenig (ark@research.att.com) wrote:
: In article <1995Jul22.022031.10937@sq.sq.com> msb@sq.sq.com (Mark Brader) writes:

: > If we're talking about C (it's hard to tell, since this entire thread
: > is cross-posted), I'd say that there's absolutely no justification for
: > adding a "bool type" to the language in the first place, and good reason
: > (as covered in the comp.lang.c FAQ list) not to do so.

: That may be true for C, but C doesn't have overloading.
: With overloaded functions, the case for bool being a
: separate type is much stronger.
: --
:     --Andrew Koenig
:       ark@research.att.com

>>>>> FFarance  <ffarance@aol.com> writes:

>> Will conditions take expressions of type bool?  How about ||, &&, ?: and
> ! ?

> You probably missed the sentence I highlighted above in my original
> posting.  Yes, they can be used in conditions (e.g., "if", "switch",
> "for", "while", "||", "&&", "?:", "!", "==").

Yep, I missed that.  However, you answered my simple question and ignored
my point.  So here it is again:

If so, conversion of values other than 1 and 0 must be defined.  If people
rely on, say, integer 42 being treated as 'true' in C89, it must still be
treated as 'true' in C9X, or everything will break.

Jason

Jonathan de Boyne Pollard (JdeBP@jba.co.uk) wrote:
> I'd far rather have a language where it was actually an *error* to apply
> meaningless operators to fundamental types, rather than have them covertly
> behave in non-intuitive fashions.

This entire discussion reminds me of two things I hate, both of which can
be compared to C++.

The first is MS-DOS: most Pentium owners are running an OS designed for
early-80s computers in the name of backward compatability. This is
especially silly in the case of C++, since most of the compatability with
C is pointless: if you want to use C code, use C!  If you are just
"converting" your code to C++ by making a few minor corrections in
syntax, you are obviously missing the point of C++.

The second is Pascal: it is one of those languages that doesn't allow good
style, doesn't encourage good style, but *enforces* *one* style considered
by its creator to be good. The syntax of C allows the any disgusting
kludge one can imagine, *but that's why they invented warnings*. It seems
like it would be quite simple to have <bool>++ generate a warning which
could be turned off (this is a standard feature on compiler I use, and
most others, I'd imagine). That way those who want that feature can have
it, and those who are opposed to it may turn on the warning.

--
/********************************************/
 #define REAL_NAME "John Williams"
 #define E_MAIL    "johnw@jove.acs.unt.edu"
 #define HOMEPAGE  "http://www.unt.edu/~johnw"
/*********************************************/
Quote of the day:
When all other means of communication fail, try words.

> There's absolutely no justification in adding all sorts of stupid and
> non-obvious quirks to the bool type (such as the example under discussion
> of allowing the ++ operator) ...

If we're talking about C (it's hard to tell, since this entire thread
is cross-posted), I'd say that there's absolutely no justification for
adding a "bool type" to the language in the first place, and good reason
(as covered in the comp.lang.c FAQ list) not to do so.
--
Mark Brader, msb@sq.com       "C and C++ are two different languages.
SoftQuad Inc., Toronto         That's UK policy..."  -- Clive Feather

This article is in the public domain.

From: mfx@cs.tu-berlin.de (Markus Freericks)
Subject: Re: Incrementing a bool

In article <3uf344$pvr@tools.near.net> barmar@nic.near.net (Barry Margolin) wri
tes:
> It's much easier to edit a couple of variable declarations, or very often
> just one macro or typedef in a header file, than to find all the places
> where you use <boolvar>++ and fix them.

Since the compiler would produce typecheck warnings/errors (*) for each
occurence of a <boolvar>++, the "finding" would be no problem.  I suppose
the motivation of people who convert ints into bools in existing programs
is to clean up their code. Removing (IMHO) dangerous practices (**) like
<boolvar>++ would clearly fit that motivation.

-- Markus

(*) Maybe <boolvar>++ could be introduced as a "deprecated" feature?
(**) I know a project that lost more than a few man-days due to a bug
that involved <int-representing-a-flag>++. Some idiot had come across
the oh-so-succinct formulation
        if (static_init_done_flag++) return;
        [...init code that should *never* be run twice...]
;-)

---------------------------------------------
* Processed by ViaUUCP! v1.00  for WILDCAT! *
---------------------------------------------

In article 6r9@aisb.ed.ac.uk, andrewfg@aisb.ed.ac.uk (Andrew Fitzgibbon) writes:
>
> Well, let them define their own operator++ then.  Honestly, I don't know
> when was the last time any of the "C compatibility" proponents actually
> tried to convert some "dusty deck" code to C++.

Many of them do it frequently, but that's not the issue.

The issue is that there is a lot of existing C++ code that uses the idiom,
and we really don't want to cause any more pain than necessary.  For many
programmers the only change necessary to use "bool" is in one header.  We
would like to keep it that way.

By the way, you can't define new operators for a built-in type.

> It's *already* bloody difficult, unless you're simply compiling C with a
> C++ compiler, and then why bother?

Perhaps because you want to write additions to the code in C++?

> If one is "converting" old code to C++, presumably one is converting not to
> the language, but to the paradigm.  In that case there is a lot more to fix
> than altering simple idioms that *can easily generate a diagnostic*.  D&E
> complains about implicit int being a pain in the parser, but it's easier to
> add correct "int" declarations to existing functions than it is to
> protoize.  Why are we stuck with it?

Sorry, but life's like that sometimes.  Compatibility with C is a very important
issue with many people, and it would be very difficult to get some national
bodies to support any ISO standard that didn't justify every incompatibility as
necessary.

Many of the uglier aspects of C++ would have disappeared long ago if we
actually had the option of cutting the ties to C.

-Mike Ball-
SunPro Developer Products.

Mike Ball (ball@Eng.Sun.COM) wrote:
: The issue is that there is a lot of existing C++ code that uses the idiom,
: and we really don't want to cause any more pain than necessary.

Then let them stick to using `int' and not change their code at all!

Really, it amazes me that the whole idea of providing a strict boolean type
is being scuppered by those who want it to be a plug-in replacement for
int.

If you want `int' then BLOODY USE INT.

Mike Ball (ball@Eng.Sun.COM) wrote:
: The issue is that there is a lot of existing C++ code that uses the idiom,
: and we really don't want to cause any more pain than necessary.

Incidentally, it's time for another reminder.

There are *no* existing idioms for `bool'.  People do *not* write

       bool p = false ;
       ..
       ..
       if ( blah ) ++p ;

All of the existing idioms are for `int'.  What they actually write is

       int p = 0 ;
       ..
       ..
       if ( blah ) ++p ;

If "least pain" is the principle, then leaving the code exactly as it is is
the least pain.  Although it may be inherently risky as it stands (due to
overflow and the like) there's nothing about introducing a `bool' type that
is going to break that code if it is left exactly as it is.

What we are talking about here are programmers that WANT TO CHANGE their
code, in order to take advantage of a NEW facility.  If it turns out that
their existing code was misusing the idea of a boolean, by incrementing it,
shifting it, or whatever, then they DESERVE a diagnostic.  It's the safer
route, because it may catch misuses of boolean variables that they never
realised that they had.

I'd far rather have a language where it was actually an *error* to apply
meaningless operators to fundamental types, rather than have them covertly
behave in non-intuitive fashions.

    int found = 0 ;
    for ( int i = 0 ; i < max ; ++ i )
 if ( something[i] ) ++found ;
    //
    // ... lots more code that uses `found' as a flag
    //
    // ... until :
    //
    for ( int j = 0 ; j < found ; ++j ) {
 //
 // Allowing `++' on `bool' means that I'm not told that I'm
 // doing something stupid in this code when I change `found' from
 // integer to boolean.
 //
    }

In article <3uh5dg$cku@silver.jba.co.uk> JdeBP@jba.co.uk (Jonathan de
Boyne Pollard) writes:

|> Andrew Koenig (ark@research.att.com) wrote:
|> : In article <3ueanu$5ue@silver.jba.co.uk> JdeBP%utopium@jba.co.uk writes:
|> :
|> : > There's absolutely no justification in adding all sorts of stupid and
|> : > non-obvious quirks to the bool type (such as the example under discussion
|> : > of allowing the ++ operator) so that existing code "works without
|> : > alteration" when the people who will be wanting to convert to using `bool'
|> : > instead of `int' (or `unsigned char') will be having to edit their code
|> : > *anyway* in order to do so.
|> :
|> : Of course there is: that's what the committee voted for.
|> :
|> : The main advantage of a democratic process is that the result is
|> : acceptable to a large number of people.  That is also the
|> : main disadvantage.

|> If there was a justification in there, I missed it.

There is an obvious justification as to why the ++ operator is in the
C++ standard.  In fact, it is the only allowable justification
according to the standards proceedure.

If you mean to say that this does not prove it is a good thing, then I
agree.  But my idea of what is good may differ from yours; any such
`justification' I can give is not adequate to get something into (or
out of) the standard.

|> Clue : provide the *reasons* that the committee voted that way.

You'd actually have to ask each individual committee member.

At least one of the reasons why the authors of the proposal defined ++
for the bool type is that it wouldn't have passed in the committee
otherwise.  Is that the justification you are looking for?
--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                              -- Beratung in industrieller Datenverarbeitung

barmar@nic.near.net (Barry Margolin) writes:
>we know that there's a large amount of code out there that uses <bool>++,
>even though it's poor style.

Um, it was about 1982 that I went through all my code making sure it didn't
do that any more.  I switched to bvar |= 1 for a while, then I decided even
that was silly and switched to the obvious bvar = 1.

The reason I stopped using bar++ was that it broke.  There was the sad day
when a program encountered 256 errors and reported none.

I think it is *vital* that bool++ ***NOT*** be allowed in any way, shape or
form, or at the very least that a diagnostic be required on every occurrence,
because code that has it is already broken.  I do very much appreciate the
concern not to break existing *working* code, but I do not think that
silently covering up existing *bugs* helps anyone.

Note in particular that if anyone *did* intend the wrap-around-at-UCHAR_MAX
behaviour, and a maintainer *incorrectly* changes uchar to bool, the change
will introduce a bug that didn't previously exist.  This does not strike me
as helpful either.

Today I start teaching a Software Creation and Maintenance course.
One of the things I am going to try, probably with the usual lack of
success, to pound into their heads is "ask for all the static checks
you can get; use the highest checking levels on cc, gcc, lcc, and any
other compilers you can get your hands on, use lint and LC-lint with
the highest checking levels, and any other static checkers you can."
The reason I am going to preach this sermon with all the fervour I can
summon is that every time I apply a new static check to existing C code
it finds old bugs that had been successfully hiding for years.

If bool++ were an operation that actually made sense for Booleans,
well, as it happens, it is.  A lot of people think of the Booleans
as somehow related to the ring Z[[2]], in which addition corresponds
to exclusive or.  I would expect
 bool ++
to mean bool = bool + 1
and I would expect the + to be interpreted the "obvious" way, i.e.
 bool = bool ^ 1
So the proposal is triply damnable:
(a) it will silently introduce bugs into correct code if an excusable
    and likely maintenance error is made;
(b) it will silently mask bugs in what we are told is a "large amount"
    of existing code, when the long-term cost is likely to be minimised
    by exposing them (which can be done without breaking correct code)
(c) it will mislead new programmers

Save us from our "friends".
--
"The complex-type shall be a simple-type."  ISO 10206:1991 (Extended Pascal)
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.

Mike Ball (ball@Eng.Sun.COM) wrote:
< andrewfg@aisb.ed.ac.uk (Andrew Fitzgibbon) writes:
< > [converting "dusty deck" code to C++]
< > It's *already* bloody difficult, unless you're simply compiling C with a
< > C++ compiler, and then why bother?

< Perhaps because you want to write additions to the code in C++?

That's what extern "C" wrappers are for.  If you want be sure that the old
code continues working, don't edit the file.  If you need to add to the
code, add a function call, add the function in a new file.  If you don't
like the mix, get funding for 6 person-months and convert to C++.

< Many of the uglier aspects of C++ would have disappeared long ago if we
< actually had the option of cutting the ties to C.

Many of the uglier aspects of C++ are not *in* C :-).

Noone wants to *cut* the ties to C, but noone expects to take dusty deck C,
run it through a C++ compiler and have it run.  We want to write our
function bodies (the bits that actually make the program work, remember) in
augmented C, but write our interfaces in something like C++.

For new code, many idioms have changed -- by and large
for the better -- and we like it that way.  For old, working, code, the
only way to guarantee that it stays working is to compile it with a C
compiler, but call it through extern "C" wrappers.

A.

--
Andrew Fitzgibbon (Research Associate),                     andrewfg@ed.ac.uk
Artificial Intelligence, Edinburgh University.               +44 031 650 4504
<a href=http://www.dai.ed.ac.uk/staff/personal_pages/andrewfg> Home Page </a>
                         "Never say there is no way" -- me.

In article <3uh55u$cke@silver.jba.co.uk> JdeBP@jba.co.uk (Jonathan de Boyne Pollard) writes:

>
> Incidentally, it's time for another reminder.
>
> There are *no* existing idioms for `bool'.  People do *not* write
>
>        bool p = false ;
>        ..

Really?  Then how come I've seen so much code that does actually say
something like
 bool p = false;
or
 BOOL p = false;?
I certainly admit that most of that code is preceded by something like
#include <bool.h>, to be sure.

The point is that there is an awful lot of code out there that does
use variables declared to be type 'bool'.  'bool' turns out, in the
end, to be a typedef or an enum, but it's just wrong to say that
nobody writes code with variables declared to be type bool.

The whole justification for adding bool to the C++ language in the
first place, in my opinion, is just that these typedefs and enums were
so common.  Every different library or framework had its own
definition of bool, and these multiple definitions made
interoperability difficult.  So bool was added as a built-in type, and
defined in such a way that all you have to do is remove that typedef
from your header file and your code would continue to work.   I think
this was a wise decision.
--
Matt Austern          matt@physics.berkeley.edu
http://dogbert.lbl.gov/~matt

ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) writes:

>Today I start teaching a Software Creation and Maintenance course.

If you want to teach that course with a C-like language that has classes
and has the standard semantics for boolean, you might try Java;
the Java compiler complains `Invalid argument type boolean for ++'
when you try to apply ++ to a boolean value.

>>>>> "LW" == Lars Wirzenius <wirzeniu@cc.Helsinki.FI> writes:

 LW> All those places can be caught trivially by making ++ invalid for boolean
 LW> operators.

 LW> I can't imagine that "b++" is such an important idiom that it is worth
 LW> making the lives of millions of future programmers harder by making
 LW> C++ even more complicated than it already is.

By deprecating `b++' instead of making it ill-formed, the committee has
basically said, "a quality compiler should give you a warning if you do this"
rather than saying, "your existing code shall no longer compile."

IOW, you're not forced fix your `b++'s immediately.

That seems reasonable to me.

Michael.

In article <3uh5dg$cku@silver.jba.co.uk> JdeBP%utopium@jba.co.uk writes:

> If there was a justification in there, I missed it.

> Clue : provide the *reasons* that the committee voted that way.

Committee members are not generally required to justify their votes.
The arguments in both directions have been pretty well hashed out
in this newsgroup, I believe.
--
    --Andrew Koenig
      ark@research.att.com

In article L5L@aisb.ed.ac.uk, andrewfg@dai.ed.ac.uk (Andrew Fitzgibbon) writes:
> Mike Ball (ball@Eng.Sun.COM) wrote:
> Noone wants to *cut* the ties to C, but noone expects to take dusty deck C,
> run it through a C++ compiler and have it run.  We want to write our
> function bodies (the bits that actually make the program work, remember) in
> augmented C, but write our interfaces in something like C++.

I don't want to get into "Does!  Does not! ..." games, but I would like to
point out that others may well approach the problem differently.

> For new code, many idioms have changed -- by and large
> for the better -- and we like it that way.  For old, working, code, the
> only way to guarantee that it stays working is to compile it with a C
> compiler, but call it through extern "C" wrappers.

This is a rather limited viewpoint that may be appropriate for what you are
doing, but falls well short of being a universal law.

You don't want to hear the details of what some of our customers are doing
when migrating from C to C++, at least on a full stomach.  The interesting
part is that many of them are succeeding.  "Unclean" does not necessarily imply
"Unworking".

-Mike Ball-
SunSoft Developer Products

In article <3uh55u$cke@silver.jba.co.uk>, JdeBP@jba.co.uk (Jonathan de Boyne Pollard) writes:
|>
|> There are *no* existing idioms for `bool'.  People do *not* write
|>
|>        bool p = false ;
|>        ..
|>        ..
|>        if ( blah ) ++p ;

Well, maybe not *that*, but you would be surprised at how close some of the
code here coems to that.

What is more likely is:

 bool inited = FALSE;

 if ( !inited++ )
  do_initialization();

[Though I don't know of any place in our code where we do quite that].

|> All of the existing idioms are for `int'.  What they actually write is
|>
|>        int p = 0 ;
|>        ..
|>        ..
|>        if ( blah ) ++p ;

Nope - we definately use FALSE and TRUE, and much of our code uses a
typedef'd bool.

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

The peace of God be with you.

>>>>> On 19 Jul 1995 09:45:30 GMT, kanze@lts.sel.alcatel.de (James
Kanze US/ESC 60/3/141 #40763) said:

    James> In article <3uh5dg$cku@silver.jba.co.uk> JdeBP@jba.co.uk (Jonathan de
    James> Boyne Pollard) writes:

    James> |> Andrew Koenig (ark@research.att.com) wrote:
    James> |> : In article <3ueanu$5ue@silver.jba.co.uk> JdeBP%utopium@jba.co.uk writes:
    James> |> :
    James> |> : > There's absolutely no justification in adding all sorts of stupid and
    James> |> : > non-obvious quirks to the bool type (such as the example under discussion
    James> |> : > of allowing the ++ operator) so that existing code "works without
    James> |> : > alteration" when the people who will be wanting to convert to using `bool'
    James> |> : > instead of `int' (or `unsigned char') will be having to edit their code
    James> |> : > *anyway* in order to do so.
    James> |> :
    James> |> : Of course there is: that's what the committee voted for.
    James> |> :
    James> |> : The main advantage of a democratic process is that the result is
    James> |> : acceptable to a large number of people.  That is also the
    James> |> : main disadvantage.

    James> |> If there was a justification in there, I missed it.

    James> There is an obvious justification as to why the ++ operator is in the
    James> C++ standard.  In fact, it is the only allowable justification
    James> according to the standards proceedure.

    James> If you mean to say that this does not prove it is a good thing, then I
    James> agree.  But my idea of what is good may differ from yours; any such
    James> `justification' I can give is not adequate to get something into (or
    James> out of) the standard.

    James> |> Clue : provide the *reasons* that the committee voted that way.

    James> You'd actually have to ask each individual committee member.

    James> At least one of the reasons why the authors of the proposal defined ++
    James> for the bool type is that it wouldn't have passed in the committee
    James> otherwise.  Is that the justification you are looking for?

Isn't it rather ironic that Dr Stroustrup once talked about C++ never
being influenced by a committee or consensus?

No matter what you say, in this thread itself I'm yet to see one
person who argues (other than by citing majority) this (operator++ on
bool) is the most intuitive/right/reasonable (or only) thing to do.

I'm afraid that Jonathan's remark about "found" being used as a count
of the number of items found (as opposed to a *boolean* "found") could
turn out to be true. I've done it myself when extending code written
by someone else i.e seen "more" to what his code does than what he
intended and used it to my advantage. Imagine such a piece of legacy
code in a library...

One of the characteristics of a programming language is to prevent
multiple interpretations (or semantic overloading) of code
fragments. The ground irony is that this was a guiding principle in
not allowing user defined operators or user defined semantics
(precedence and sisters) to existing operators (and cautioning people
to overload existing operators with semantics as close as possible to
the "generally" accepted idea). Now builtin operators have
non-intuitive semantics on builtin types!

There is certainly the possibility that the majority that voted for
operator++ on bool wasn't aware of the dangers of
misinterpretation. Maybe they weren't so serious about it in the first
place. I'd expected majority to be balanced with reasoning. But in
this case, reasoning has had no place.

By the way, these are my personal opinions.

--
Peace.... +<:-)

Anil
akv@cacs.usl.edu
s5vijen@watson.ibm.com

In article <KANZE.95Jul19114530@slsvhdt.lts.sel.alcatel.de>
kanze@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763) writes:

> At least one of the reasons why the authors of the proposal defined ++
> for the bool type is that it wouldn't have passed in the committee
> otherwise.

How interesting! If the advocates of the built-in bool would have done the
right thing, which is not to define ++ on it, than the committee would
have done the right thing too, which is not to have the built-in bool at
all. The built-in bool is just an unfortunate accident!

(Sorry, I just couldn't resist.)

- Wil

Andrew Koenig (ark@research.att.com) wrote:

: Of course there is: that's what the committee voted for.

: The main advantage of a democratic process is that the result is
: acceptable to a large number of people.  That is also the
: main disadvantage.
: --

I hardly call the committee a democracy - they are not even elected. Even if
they were representative-democracy is not as good as participative-democracy
in producing a result acceptable to a large number of people.

--
Stephen Baynes                              baynes@mulsoc2.serigate.philips.nl
Philips Semiconductors Ltd
Southampton                                 My views are my own.
United Kingdom

In article 4xt@ukpsshp1.serigate.philips.nl, baynes@ukpsshp1.serigate.philips.nl (Stephen Baynes) writes:
>Andrew Koenig (ark@research.att.com) wrote:
>
>: Of course there is: that's what the committee voted for.
>
>: The main advantage of a democratic process is that the result is
>: acceptable to a large number of people.  That is also the
>: main disadvantage.
>
>I hardly call the committee a democracy - they are not even elected. ...
>
>Stephen Baynes                              baynes@mulsoc2.serigate.philips.nl
>Philips Semiconductors Ltd
>Southampton                                 My views are my own.
>United Kingdom

Sure they are. Every organization with a legitimate interest in C++ can elect
its own representative. If you are not employed by such an organization, you
can even elect yourself to represent yourself. That seems to me to be more
democratic than the governmental systems of the US or the UK. Can Philips
Semiconductors get a vote in Parliament?** It can get a vote in X3J16. The
"poll tax" for voting in X3J16 is higher than for voting in the US or UK,
but much less than the cost of becoming elected to Parliament or Congress.
No campaigning is necessary, only one self-electing letter.

**Please, no jokes about buying legislators.
---
Steve Clamage, stephen.clamage@eng.sun.com

Stan Friesen (swf@ElSegundoCA.ATTGIS.COM) wrote:
: In article <3ud0ie$g5u@myntti.helsinki.fi>, wirzeniu@cc.Helsinki.FI (Lars Wirzenius) writes:
: |>
: |> Personally, I see no point in using "p++" instead of "p = 1" or "p = YES"
: |> (or "p = TRUE", for those who prefer that spelling), even in C.
:
: This is *not* equivalent, as the following shows:
:
:  bool p = FALSE;
:  if(p++)
:   print("executed once");
:
: versus:
:
:  bool p = FALSE;
:  if(p = true)
:   print("never, ever executed");
:
: It is *this* idiom that is broken by not having ++ defined for bool.

You've missed two things.  I'll do the less embarrasing first.

Firstly you've missed the fact that there are NO existing idioms for `bool'.
There are existing idioms for *int*.

The case for defining the ++ operator on operands of bool type is that it
is then "easy" to substitute `bool' for `int' in idioms where the
boolean-like behaviour of `int' is being used.  The counter argument to
that is that unless only the *strict* subset of integer behaviour that maps
onto boolean behaviour is being used (e.g. all of the assignments to the
variable that was `int' and is now `bool' should be of the `= 1' and `= 0'
variety) the program should be ill-formed and the programmer forced to
tighten up his use of the variable before converting from `int' to `bool'.

One of the side effects of this is of course that in such tidying the
programmer may find that an `int' is what was wanted after all, and not a
`bool' at all (an example of an integer that is used as a binary flag in
most places but as an actual counter in one obscure place in the code comes
to mind -- letting `++' silently become `= true' when `int' is changed to
`bool' will break this code).

The second thing that you've missed is that the strings in your two
examples are exactly the wrong way around.

In the first if statement, the '++' operator is a POST-increment, and so the
result of the expression is false and the print("executed once") function is
*not* called.  In the second `if' statement the result of the assignment
expression is the value assigned to the left operand, which is, in this case,
`true', and so the print("never, ever executed") function *will* be called.

In light of your typo, think on this :

If you, as a proponent of adding '++' semantics to `bool' who presumably
knows what he is talking about, can get things so mixed and muddled, what hope
have the Ordinary Programmers of this world, both in knowing what all of
these extra semantics that you are bolting onto booleans are, and in knowing
where and when said semantics match up with those of `int' ?

In article <3uf344$pvr@tools.near.net> barmar@nic.near.net (Barry Margolin) writes:
> It's much easier to edit a couple of variable declarations, or very often
> just one macro or typedef in a header file, than to find all the places
> where you use <boolvar>++ and fix them.

Since the compiler would produce typecheck warnings/errors (*) for each
occurence of a <boolvar>++, the "finding" would be no problem.  I suppose
the motivation of people who convert ints into bools in existing programs
is to clean up their code. Removing (IMHO) dangerous practices (**) like
<boolvar>++ would clearly fit that motivation.

-- Markus

(*) Maybe <boolvar>++ could be introduced as a "deprecated" feature?
(**) I know a project that lost more than a few man-days due to a bug
that involved <int-representing-a-flag>++. Some idiot had come across
the oh-so-succinct formulation
 if (static_init_done_flag++) return;
 [...init code that should *never* be run twice...]
;-)

barmar@nic.near.net (Barry Margolin):
> It's much easier to edit a couple of variable declarations, or very often
> just one macro or typedef in a header file, than to find all the places
> where you use <boolvar>++ and fix them.

All those places can be caught trivially by making ++ invalid for boolean
operators.

If they change the variable, they will have to check their code _anyway_.
Suppose they allocate booleans with malloc, and use sizeof(int) to
compute the size of a boolean?  Suppose they print it out with printf;
is bool compatible with %d (or whatever format they're using)?  Suppose
they read it in via scanf; is bool* compatible with int* ?

If they don't want to go through all that work, they can go on using
ints.

I can't imagine that "b++" is such an important idiom that it is worth
making the lives of millions of future programmers harder by making
C++ even more complicated than it already is.

--
Lars.Wirzenius@helsinki.fi  (finger wirzeniu@klaava.helsinki.fi)
NEW: Publib version 0.5: ftp://ftp.cs.helsinki.fi/pub/Software/Local/Publib/

In article <3ueanu$5ue@silver.jba.co.uk> JdeBP%utopium@jba.co.uk writes:

> There's absolutely no justification in adding all sorts of stupid and
> non-obvious quirks to the bool type (such as the example under discussion
> of allowing the ++ operator) so that existing code "works without
> alteration" when the people who will be wanting to convert to using `bool'
> instead of `int' (or `unsigned char') will be having to edit their code
> *anyway* in order to do so.

Of course there is: that's what the committee voted for.

The main advantage of a democratic process is that the result is
acceptable to a large number of people.  That is also the
main disadvantage.
--
    --Andrew Koenig
      ark@research.att.com

Barry Margolin (barmar@nic.near.net) wrote:
: In article <3ueanu$5ue@silver.jba.co.uk> JdeBP%utopium@jba.co.uk writes:
: >There's absolutely no justification in adding all sorts of stupid and
: >non-obvious quirks to the bool type (such as the example under discussion
: >of allowing the ++ operator) so that existing code "works without
: >alteration" when the people who will be wanting to convert to using `bool'
: >instead of `int' (or `unsigned char') will be having to edit their code
: >*anyway* in order to do so.
:
: It's much easier to edit a couple of variable declarations, or very often
: just one macro or typedef in a header file, than to find all the places
: where you use <boolvar>++ and fix them.

This is what line numbers in error messages are for!  Sheesh!

:                                                         On the other hand,
: we know that there's a large amount of code out there that uses <bool>++,
: even though it's poor style.

No they do not.  They use <int>++.  There are *no* existing idioms for
bool, only idioms for using the boolean-esque features of int.

This is the whole point.  People MISUSING booleans in that way can quite
easily change "++p" to "p = true" if the implementation gives a diagnostic
for the use of the `++' operator on a boolean.

It even allows the programmer to diagnose the case where they converted
`int' to `bool' and suddenly found that they were actually using the `int'
as a proper counter (rather than just a flag) in another part of the code.

Andrew Koenig (ark@research.att.com) wrote:
: In article <3ueanu$5ue@silver.jba.co.uk> JdeBP%utopium@jba.co.uk writes:
:
: > There's absolutely no justification in adding all sorts of stupid and
: > non-obvious quirks to the bool type (such as the example under discussion
: > of allowing the ++ operator) so that existing code "works without
: > alteration" when the people who will be wanting to convert to using `bool'
: > instead of `int' (or `unsigned char') will be having to edit their code
: > *anyway* in order to do so.
:
: Of course there is: that's what the committee voted for.
:
: The main advantage of a democratic process is that the result is
: acceptable to a large number of people.  That is also the
: main disadvantage.

If there was a justification in there, I missed it.

Clue : provide the *reasons* that the committee voted that way.

Barry Margolin (barmar@nic.near.net) wrote:
: >Go too far down that road and you start defining silly things just in order
: >to keep things straight, such as defining semantics for left-shifting `true'
: >and `false' or whether implementations are allowed to represent !true and
: >~true with different bit patterns "under the covers".

: This is silly.  No one (well, maybe I should play it safe and say hardly
: anyone) shifts boolean variables in existing code, so no one is going to
: propose that it be defined for the official bool type.

I said it was silly, but you were right to play it safe.

      int p_flag = 0, q_flag = 0 ;

      for ( int i = 0 ; i < argc ; ++i )
   if (!strcmp(argv[i], "-p"))
  p_flag = 1 ;
   else if (!strcmp(argv[i], "-q"))
  q_flag = 1 ;

      int combined_flags = (q_flag << 3) | (p_flag << 7) ;

It may be desired to save `combined_flags' in a configuration file or in the
header of a data file, for example.

So ... how are you going to define "compatibility semantics" for left
shifting booleans, just on the off chance that the same programmer who
converted all of his other `int's to `bool's is now going to tackle the
above snippet ?

How far down this road do you have to go before you realise that what you
are doing is simply reinventing `int' ?

In article <3uecqi$6et@silver.jba.co.uk>, JdeBP%utopium@jba.co.uk writes:
|> You've missed two things.  I'll do the less embarrasing first.
|>
|> Firstly you've missed the fact that there are NO existing idioms for `bool'.
|> There are existing idioms for *int*.
|>
|> The case for defining the ++ operator on operands of bool type is that it
|> is then "easy" to substitute `bool' for `int' in idioms where the
|> boolean-like behaviour of `int' is being used.  The counter argument to
|> that is that unless only the *strict* subset of integer behaviour that maps
|> onto boolean behaviour is being used ...

There are a great many instances in which the strict boolean subset is used
*except* that post-increment is also used.  (I even used to program that
way - note, I do agree is it questionalbe practice - that is why I stopped).

|> One of the side effects of this is of course that in such tidying the
|> programmer may find that an `int' is what was wanted after all, and not a
|> `bool' at all (an example of an integer that is used as a binary flag in
|> most places but as an actual counter in one obscure place in the code comes
|> to mind -- letting `++' silently become `= true' when `int' is changed to
|> `bool' will break this code).

But there are lots of cases where it *is* "really" a bool, the post-increment
is simply a quick way to do the equivalent of "test-and-set", rather than
"if not set then set".

That is, the "counting" behavior is *not* being used.
|>
|> The second thing that you've missed is that the strings in your two
|> examples are exactly the wrong way around.
|>
|> In the first if statement, the '++' operator is a POST-increment, ...

Yep, that was the whole point.  A post-increment behaves differently than
an assignment.

In fact it acts like the assembly "test-and-set" instruction (and could
even be *implemented* as such in C++, but not in C).

|> result of the expression is false and the print("executed once") function is
|> *not* called.  In the second `if' statement the result of the assignment
|> expression is the value assigned to the left operand, which is, in this case,
|> `true', and so the print("never, ever executed") function *will* be called.

Yep, I got the sign of the test backwards.

|> In light of your typo, think on this :
|>
|> If you, as a proponent of adding '++' semantics to `bool' who presumably
|> knows what he is talking about, can get things so mixed and muddled, what hope
|> have the Ordinary Programmers ...

No, the lesson is:

Dont' try to program when I haven't gotten enough sleep.
[Anybody have a good air conditioner for sale :-)]

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

The peace of God be with you.

Barry Margolin (barmar@nic.near.net) wrote:
< In article <3ueanu$5ue@silver.jba.co.uk> JdeBP%utopium@jba.co.uk writes:
< >There's absolutely no justification in adding all sorts of stupid and
< >non-obvious quirks to the bool type ... so that existing code "works
< >without alteration" when the people ... will be having to edit their
< >code *anyway* in order to do so.

< On the other hand, we know that there's a large amount of code out there
< that uses <bool>++, even though it's poor style.

Well, let them define their own operator++ then.  Honestly, I don't know
when was the last time any of the "C compatibility" proponents actually
tried to convert some "dusty deck" code to C++.

It's *already* bloody difficult, unless you're simply compiling C with a
C++ compiler, and then why bother?

If one is "converting" old code to C++, presumably one is converting not to
the language, but to the paradigm.  In that case there is a lot more to fix
than altering simple idioms that *can easily generate a diagnostic*.  D&E
complains about implicit int being a pain in the parser, but it's easier to
add correct "int" declarations to existing functions than it is to
protoize.  Why are we stuck with it?

A.

--
Andrew Fitzgibbon (Research Associate),                     andrewfg@ed.ac.uk
Artificial Intelligence, Edinburgh University.               +44 031 650 4504
<a href=http://www.dai.ed.ac.uk/staff/personal_pages/andrewfg> Home Page </a>
                         "Never say there is no way" -- me.
--
Andrew Fitzgibbon (Research Associate),                     andrewfg@ed.ac.uk
Artificial Intelligence, Edinburgh University.               +44 031 650 4504
<a href=http://www.dai.ed.ac.uk/staff/personal_pages/andrewfg> Home Page </a>
                         "Never say there is no way" -- me.

In article <3ueanu$5ue@silver.jba.co.uk> JdeBP%utopium@jba.co.uk writes:
>There's absolutely no justification in adding all sorts of stupid and
>non-obvious quirks to the bool type (such as the example under discussion
>of allowing the ++ operator) so that existing code "works without
>alteration" when the people who will be wanting to convert to using `bool'
>instead of `int' (or `unsigned char') will be having to edit their code
>*anyway* in order to do so.

It's much easier to edit a couple of variable declarations, or very often
just one macro or typedef in a header file, than to find all the places
where you use <boolvar>++ and fix them.

>Go too far down that road and you start defining silly things just in order
>to keep things straight, such as defining semantics for left-shifting `true'
>and `false' or whether implementations are allowed to represent !true and
>~true with different bit patterns "under the covers".

This is silly.  No one (well, maybe I should play it safe and say hardly
anyone) shifts boolean variables in existing code, so no one is going to
propose that it be defined for the official bool type.  On the other hand,
we know that there's a large amount of code out there that uses <bool>++,
even though it's poor style.
--
Barry Margolin
BBN Planet Corporation, Cambridge, MA
barmar@bbnplanet.com
Phone (617) 873-3126 - Fax (617) 873-5124

Andrew Koenig (ark@research.att.com) wrote:
: The intent is to allow programmers who use int values as booleans
: and set them to true by applying ++ to them to change them to type bool
: without changing alll the places they're used.
:
: Wise or not, the practice of using ++ to make a variable "true"
: is widespread.

Then let them continue to use those int values as booleans!

There's absolutely no justification in adding all sorts of stupid and
non-obvious quirks to the bool type (such as the example under discussion
of allowing the ++ operator) so that existing code "works without
alteration" when the people who will be wanting to convert to using `bool'
instead of `int' (or `unsigned char') will be having to edit their code
*anyway* in order to do so.

Go too far down that road and you start defining silly things just in order
to keep things straight, such as defining semantics for left-shifting `true'
and `false' or whether implementations are allowed to represent !true and
~true with different bit patterns "under the covers".

If people want to do silly things with ints, then let them continue to do
so.  But REQUIRE them to tidy up their concepts of boolean variables so that
they include the common criteria that booleans can ONLY HAVE TWO VALUES and
ONLY RESPOND TO A LIMITED SET OF OPERATIONS before they can convert such
code to using `bool'.



[[ One has to wonder : Are the people promoting the idea of adding arbitrary
and non-obvious semantics to the `bool' type for the sake of mere and
somewhat dubious convenience the same C++ programmers who scream loudly
and long when others suggest that "for convenience" it would be nice to add
in members to class definitions after the fact ? ]]