From: daveg@synaptics.com (Dave Gillespie)
Newsgroups: comp.lang.c++
Subject: Re: boolean (was: Re: typedef vs enum)
Date: 21 Jul 92 05:05:52 GMT
Organization: Synaptics, Inc., San Jose, CA
In-reply-to: dougm@titan.cs.rice.edu's message of 20 Jul 92 04:27:28 GMT

In article <DOUGM.92Jul19222728@titan.cs.rice.edu> dougm@titan.cs.rice.edu (Doug Moore) writes:
Andrew> 	if (t!=0) cout << "Balderdash!\n";
> 
> You are right.  I was rash.
> I am stung by your balderdash.
> But if one bang just won't do,
> Let's instead just make it two.
> 
>   In other words, try to find an anomaly with literals t!! and f!!.

[insert poetry here to taste]

If you define "t!!" as a "t" token followed by two "!" tokens, using
the existing C++ lexical rules, then you still have the same sort of
problem:  "if (t!!==2)" cannot be scanned properly (not left-to-right,
anyway).

If you define "t!!" as a single token, may the fleas of a thousand
camels, well, you get the idea.  :-)

Let's do away with t!! and f!! altogether:  The expressions !!1 and
!!0 are just as simple, and we get them for free.  I find them easier
to tell apart at a glance, too.


Under "advantages," you might list the ability of a class to define
"operator boole()" conversions instead of/as well as "operator int()".
Many classes define misleading "int" conversions when they really
want only a boolean conversion.

I worried for a moment about boolean bit-fields, but then I remembered
that C++ allows bit-fields of any integral type (unlike ANSI C).
That's good.

Is it possible for a template "Array<boole>" to define itself
naturally as a packed bit vector?  That would be pretty cool.

Does there need to be any mention of "signed", "unsigned", "short",
and "long" as applied to "boole"?  (Specifically, that all of these
are disallowed?)


One thing I worry about with this proposal is the ability to write
programs to work equally well with pre- and post-"boole" C++.  I don't
know what preprocessor name is being used to identify ANSI C++, but
suppose it's __STDCPLUS__.  I thought about putting a simple

#ifndef __STDCPLUS__
typedef int boole;
// or: #define boole int
#endif

at the front of my program, but that's not enough:  There will be
situations where in ANSI C++ I want to overload like this,

class Foo {
  void bar(int x) { ... }
  void bar(boole x) { ... }
  operator int() { ... }
  operator boole() { ... }
};

the typedef trick won't work because now we have multiple conflicting
declarations when we use an old-style compiler.  Every one of these
would also have to be guarded by #ifdef's.

What can be done to ease the transition from current C++ to C++
with booleans?


I like the way the boolean type solves all the ills of the "&&=/||="
proposals.  There is no issue of normalizing the values to 0/1, because
we know we're working with booleans already.  Very nice.

> The behavior of an expression of the form E1 &&= E2 is equivalent to
> E1 ? (E1=(E2)) : f!, except that E1 is evaluated only once.

Any reason you wrote it that way instead of as "E1 = E1 && E2"?  The
only way I can see that this would make a difference is if "E1" is a
volatile variable.  Is that rare case worth sacrificing the elegance
of defining "E1 <op>= E2" as "E1 = E1 <op> E2" always?


There is a minor typo in section 1 of your proposal:

> When arithmetic or pointer types appear in a
> context that requires a boolean value, standard logical conversions
> are applied to convert nonzero arithmetic and nonnull pointer types to
> f!.

This should be t! (or, possibly, !!1).

								-- Dave
--
Dave Gillespie
  daveg@synaptics.com, uunet!synaptx!daveg
  or: daveg@csvax.cs.caltech.edu