In <425umg$n9b@news1.halcyon.com>, aitken@coho.halcyon.com (William E. Aitken) writes:
> #define true (1||true)

This approach had not occured to me (assuming that it works <g>).
Your idea for a definition of true (and its dual for false) is excellent
if the committe doesn't get the point.  This is the most useful idea
to come of the entire discussion -- barring the chance that the
discussion will get the idea across to the committe and they will
actually change the draft standard (perhaps with a wording such
as you suggested).

When I wrote the original post starting this thread I was hoping to
simply be told that the draft standard treated this correctly.
However, it started a looong thread where about half the people
want it treated properly and about half are appalled at the very
idea (don't ask me why, I guess they like programming in binary <g?).

Michael Lee Finney



---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

In article <9508310634.1386@mulga.cs.mu.OZ.AU>
           fjh@munta.cs.mu.OZ.AU "Fergus Henderson" writes:

> "Brian T. Hill" <bhil@strata3d.com> writes:
>
> >Who wants to use "true" or "false" in the preprocessor anyway?
>
> I do.
>
> >What are you going to do:  #if true ... ?
>
> Yes!  Amoung other uses, I'd use `#if true' rather than `#if 1'.
> I don't use `#if 1' very often, but I do use it occaisionally...
> The code ususally looks something like this:
>
>         #if 1
>                 // alert! this is a temporary hack!!
>                 hack(); hack(); hack();
>         #else
>                 // this code disabled because ...
>                 ...
>         #endif

What's so wrong with saying what you mean:

    #ifndef USE_ORIGINAL_UNHACKED_CODE
        hack(); hack(); hack();
    #else
        // This code disabled because
        ...
    #endif

The point is why change the language to support your idiosyncacies?

--
Alan Griffiths               | Also editor of: The ISDF Newsletter
Senior Systems Consultant,   | (An Association of C and C++ Users publication)
CCN Group Limited.           | (ISDF editor  : isdf@octopull.demon.co.uk)
(agriffiths@ma.ccngroup.com) | (For ACCU see : http://bach.cis.temple.edu/accu)
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

"Brian T. Hill" <bhil@strata3d.com> writes:

>Who wants to use "true" or "false" in the preprocessor anyway?

I do.

>What are you going to do:  #if true ... ?

Yes!  Amoung other uses, I'd use `#if true' rather than `#if 1'.
I don't use `#if 1' very often, but I do use it occaisionally...
The code ususally looks something like this:

 #if 1
  // alert! this is a temporary hack!!
  hack(); hack(); hack();
 #else
  // this code disabled because ...
  ...
 #endif

>In setting compiler directives, what's so bad about 1 and 0 (they
>generally tend to be somewhat isolated and the point should be clear
>anyway):

What's so bad about wanting to say what you mean?  Why are people so
opposed to what would be a *trivial* change to the preprocessor?

I don't want to have to explain to students why `true' doesn't work
in the preprocessor.

--
Fergus Henderson             |  #define x t=a[i],a[i]=a[m],a[m]=t
                             |  char a[]=" 12345678";main(m,i,j,t){for(i=m;i<
fjh@cs.mu.oz.au              |  9;x,i++)for(x,j=m;--j?(t=a[m-j]-a[m])-j&&t+j:
http://www.cs.mu.oz.au/~fjh  |  main(m+1)*0;);m-9||puts(a+1);} /* 8 queens */
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

: What's so wrong with saying what you mean:
:
:     #ifndef USE_ORIGINAL_UNHACKED_CODE
:         hack(); hack(); hack();
:     #else
:         // This code disabled because
:         ...
:     #endif
:
: The point is why change the language to support your idiosyncacies?

Right now #if 0 /#if 1 is supported.

What about code that you'd expect to work:

#define USE_FEATURE_FOO true

#if USE_FEATURE_FOO
 /* This code isn't included */
#endif

Whereas,

#define USE_FEATURE_FOO 1

#if USE_FEATURE_FOO
 /* This code is included */
#endif

That's why the preprocessor should know about true/false.  It should
not expand them into 1/0, but rather it should accept them in the
context of #if expressions as 1.

Here's a case where #if true would happen, given the macro expansion
of USE_FEATURE_FOO.  I think therefore it is useful.  Otherwise, there
will be many hard to find bugs until people get burned by this.

Unfortunately, this change would make the preprocessor part of the
language different than ANSI-C.

 [ The C++ preprocessor is already quite different to C-89:
   it has new keywords, "//" comments, and digraphs.
   So I don't really understand the reluctance to modify
   the preprocessor.
  -fjh (moderator).
 ]

Warner
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

In article <809869855snz@ma.ccngroup.com>,
Alan Griffiths  <aGriffiths@ma.ccngroup.com> wrote:
>In article <9508310634.1386@mulga.cs.mu.OZ.AU>
>           fjh@munta.cs.mu.OZ.AU "Fergus Henderson" writes:
>
>> "Brian T. Hill" <bhil@strata3d.com> writes:
>>
>> >Who wants to use "true" or "false" in the preprocessor anyway?
>>
>> I do.
>>
>>
>>         #if 1
>>                 // alert! this is a temporary hack!!
>>                 hack(); hack(); hack();
>>         #else
>>                 // this code disabled because ...
>>                 ...
>>         #endif
>
>What's so wrong with saying what you mean:
>
>    #ifndef USE_ORIGINAL_UNHACKED_CODE
>        hack(); hack(); hack();
>    #else
>        // This code disabled because
>        ...
>    #endif
>
>The point is why change the language to support your idiosyncacies?


Another important advantage of using the descriptive preprocessor macro
names is that it is a much easier and more flexible when there is a need
to selectively turn on/off certain hacks.

It is very rare that all the hacks and conditionals get turned
on or off at the same time. Selectively controlling which hacks or
conditional code gets compiled in is much easier when descriptive
#if guards are used rather than #if 1 or #if true. And once you decide
to use descriptive names, there is very little difference between:

#define USE_ORIGINAL_UNHACKED_CODE 1
#define WORK_AROUND_CTOR_BUG       0

and

#define USE_ORIGINAL_UNHACKED_CODE true
#define WORK_AROUND_CTOR_BUG       false


--
Ajay Kamdar                               Email: ajay@lehman.com
Lehman Brothers                           Phone: (201) 524-5048

[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

The arguments for and against making the preprocessor recognize true and
false seem to be:

For:
  1) Why not?
  2) Uniformity
Against:
  1) Why bother?

I have personally encountered a case where it would have been nice for the
preprocessor to recognize true and false:  Rogue Wave Tools.h++ uses
a typedef RWBoolean and macros TRUE and FALSE for dealing with boolean
values.  I tried converting it over to using the bool type one day, by
replacing 'int' with 'bool' in the typedef and '1' and '0' with 'true' and
'false'.  This worked fine for actual code that used the TRUE and FALSE
macros, but where they appeared in preprocessor directives I had to replace
them with something else.  Why should this be necessary?

Jason

---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

Alan Griffiths <aGriffiths@ma.ccngroup.com> writes:

>What's so wrong with saying what you mean:
>[...alternative code not using `#if true'...]

There's nothing wrong with that.  I'm not suggesting that making the
preprocessor recognize `true' would add any significant additional
functionality to the language - clearly using `1' suffices.  Rather,
I'm suggesting that it would make the language easier to learn and
easier to use, and perhaps make some programs very slightly easier to
read and understand.  Sure, you can write it using `1', but shouldn't
the version using `true' work too?

>The point is why change the language to support your idiosyncacies?

I hope that the language will be changed, not to support my
idiosyncracies, but simply *because it makes sense*.  The change would
be trivial to implement, and if we don't make this change, then we
leave C++ with yet another nasty little trap for the unwary.

--
Fergus Henderson             |  #define x t=a[i],a[i]=a[m],a[m]=t
                             |  char a[]=" 12345678";main(m,i,j,t){for(i=m;i<
fjh@cs.mu.oz.au              |  9;x,i++)for(x,j=m;--j?(t=a[m-j]-a[m])-j&&t+j:
http://www.cs.mu.oz.au/~fjh  |  main(m+1)*0;);m-9||puts(a+1);} /* 8 queens */
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

Fergus Henderson (fjh@munta.cs.mu.OZ.AU) wrote:
:  #if 1
:   // alert! this is a temporary hack!!
:   hack(); hack(); hack();
:  #else
:   // this code disabled because ...
:   ...

I prefer:
 #ifdef PUT_BUG_DESCRIPTION_HERE
   // this code disabled because ...
   ...
  #else
   // alert! this is a temporary hack!!
   hack(); hack(); hack();
 #endif

This way, I can toggle which code to use without editing the file.

--
Micha Berger 201 916-0287        Help free Ron Arad, held by Syria 3224 days!
aishdas@haven.ios.com                     (16-Oct-86 -  1-Sep-95)
<a href=news:alt.religion.aishdas>Orthodox Judaism: Torah, Worship, Kindness</a>
<a href=http://haven.ios.com/~aishdas>AishDas Society's Home Page</a>
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

mfinney@inmind.com writes:

>In <4167na$nv9@engnews2.Eng.Sun.COM>, herbs@interlog.com (Herb Sutter) writes:
>>Here's the point that's perhaps being missed: The problem which the built-in
>>type 'bool' (and the literals 'true' and 'false') fixed does not exist in the
>>preprocessor (no automatic conversions, etc.), so unless you can correct me
>>and point out a benefit to suddenly putting a type into the preproc, I'm
>>afraid I don't see your point.

>Herb, since 'true' is a literal, I should be able to write 'true" as a constant in
>both the preprocessor and in C++ itself.  The benefit is that you don't have
>two or more multiple names for exactly the same thing.  And again, you do
>NOT introduce a type in the preprocessor by allowing it to recognize a
>literal.  Why does everybody keep talking about "types" when I am talking
>about "literals"?  The strings '0' and 'a' but nobody worries that the
>preprocessor needs to interpret '0' as a "type" of int and 'a' as a "type" of
>char.

But that is not the case.

There are no types in the preprocessor, not even literal chars. Chars
and wide chars are treated as their integer values.  There are no enums,
pointers, or floating-point values. The result of any comparison is the
integer value 0 or 1.

If true and false were introduced into the preprocessor, they would
have to be predefined to the preprocessor numbers 1 and 0. They would
then be the only prefined literals in the preprocessor. Why would this
be superior to just using 1 and 0 in your code, given that there are
no types to begin with? That is, IMHO 'true' gives no advantage
whatever over '1' in a preprocessor expression, since it cannot mean
anything different from '1', and since it must iteract with expressions
with integer (not boolean) values.

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

Distribution:
clamage@Eng.Sun.COM (Steve Clamage) writes:
>
>mfinney@inmind.com writes:
>
>>In <4167na$nv9@engnews2.Eng.Sun.COM>, herbs@interlog.com (Herb Sutter) writes:
>>>Here's the point that's perhaps being missed: The problem which the built-in
>>>type 'bool' (and the literals 'true' and 'false') fixed does not exist in the
>>>preprocessor (no automatic conversions, etc.), so unless you can correct me
>>>and point out a benefit to suddenly putting a type into the preproc, I'm
>>>afraid I don't see your point.
>
>>Herb, since 'true' is a literal, I should be able to write 'true" as a constant in
>>both the preprocessor and in C++ itself.  The benefit is that you don't have
>>two or more multiple names for exactly the same thing.  And again, you do
>>NOT introduce a type in the preprocessor by allowing it to recognize a
>>literal.  Why does everybody keep talking about "types" when I am talking
>>about "literals"?  The strings '0' and 'a' but nobody worries that the
>>preprocessor needs to interpret '0' as a "type" of int and 'a' as a "type" of
>>char.

The point is that you wouldn't be including 'true' and 'false' into the preproc
with the same meaning as in the language; they would only be macros for 1 and 0,
respectively.  Since we're gaining none of the benefits of the literals, why bother
introducing them (with yet another meaning)?  Why not just use 1 and 0 with no
renaming at all?

They do give a benefit in the language itself, but none of those benefits apply here.
That's what I'm trying to get at.

>If true and false were introduced into the preprocessor, they would
>have to be predefined to the preprocessor numbers 1 and 0. They would
>then be the only prefined literals in the preprocessor. Why would this
>be superior to just using 1 and 0 in your code, given that there are
>no types to begin with? That is, IMHO 'true' gives no advantage
>whatever over '1' in a preprocessor expression, since it cannot mean
>anything different from '1', and since it must iteract with expressions
>with integer (not boolean) values.

Steve's last phrase may answer your question about 'why is everyone talking about
types when I'm talking about literals'... there are no types in the preproc, and
if we included the literals 'true' and 'false' as you ask then either: a) we
introduce a type into the preproc to let these two literals maintain their existing
meaning; or b) the literals lose their existing meaning anyway and aren't (can't be)
any different from plain 1 and 0, which doesn't seem to achieve much of anything in
particular.  Hence the mini-discussion of (a) and reasons to avoid it. :-)


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Herb Sutter                 2228 Urwin, Ste 102         voice (416) 618-0184
Connected Object Solutions  Oakville ON Canada L6L 2T2    fax (905) 847-6019


---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

Distribution:
Who wants to use "true" or "false" in the preprocessor anyway?  What are
you going to do:  #if true ... ?

In setting compiler directives, what's so bad about 1 and 0 (they
generally tend to be somewhat isolated and the point should be clear
anyway):

#define qDebug 1
#define qUseOptimizations 0

and so on.

---------------------------
Brian T. Hill
bhil@strata3d.com
http://park.uvsc.edu/~bhil/



---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

Distribution:

>mfinney@inmind.com writes:
>>The benefit is that you don't have
>>two or more multiple names for exactly the same thing.  And again, you do
>>NOT introduce a type in the preprocessor by allowing it to recognize a
>>literal.  Why does everybody keep talking about "types" when I am talking
>>about "literals"?  The strings '0' and 'a' but nobody worries that the
>>preprocessor needs to interpret '0' as a "type" of int and 'a' as a "type" of
>>char.

Steve Clamage <clamage@Eng.Sun.COM> wrote:
>But that is not the case.
>
>There are no types in the preprocessor, not even literal chars. Chars
>and wide chars are treated as their integer values.  There are no enums,
>pointers, or floating-point values. The result of any comparison is the
>integer value 0 or 1.
>
>If true and false were introduced into the preprocessor, they would
>have to be predefined to the preprocessor numbers 1 and 0. They would
>then be the only prefined literals in the preprocessor. Why would this
>be superior to just using 1 and 0 in your code, given that there are
>no types to begin with? That is, IMHO 'true' gives no advantage
>whatever over '1' in a preprocessor expression, since it cannot mean
>anything different from '1', and since it must iteract with expressions
>with integer (not boolean) values.

I'm not sure about this.  What about cases like this:


 #define DEBUG false


 bool debug = DEBUG;


 #if DEBUG
  // do debug stuff
 #endif /* DEBUG */


 if (DEBUG) {
  // do debug stuff
 }


 debug_message (DEBUG);  // what if overloaded with int?



This seems to indicate a need for "false" to be synonymous with "0" to
the preprocessor.  Automatic int to enum conversion (ugh) lets you use
"0" for all except the last case.  --Alan Char

---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

In <MATT.95Aug20111450@Austern>, herbs@interlog.com (Herb Sutter) writes:
> Since we're gaining none of the benefits of the literals, why bother
>introducing them (with yet another meaning)?  Why not just use 1 and 0 with no
>renaming at all?

This is where, I think, we are fundamentally disagreeing.  There is a
benefit, and (to me) a major one.  That is readability.  I consider
using '1' and '0' for logical conditions to be "bad form", and
considering the number of people that define TRUE/FALSE in some variant
for the preprocessor I am not alone in that feeling.

As long it is a literal which can be converted to an integral value, I
just don't see the problem in allowing the preprocessor to recognize
the literal.  If you want to use '1' and '0' there is nothing stopping
you.  But I don't want to do that.  And the inability of the
preprocessor to recognize the 'true' / 'false' literals DOES stop me
from writing (what I consider to be) readable code.

Michael Lee Finney
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

In <419fk4$75b@news1.halcyon.com>, aitken@coho.halcyon.com (William E. Aitken) writes:
> Unfortunately, it's even worse than that.   The preprocessor will
>NOT complain about true.   This can cause some rather unpleasant surprises,

Ouch!  That makes it even MORE imperative that they fix the problem!
Nothing like breaking our code silently!  What they always try to avoid
doing, but seem intent on now.


Michael Lee Finney
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

Steve Clamage, stephen.clamage@eng.sun.com:
> You could #define something other than 'true' and 'false' (e.g. True, False)
> to have the values 1 and 0 if you want, or you could just use the built-in
> zero/not-zero dichotomy.

But if the preprocessor doesn't "understand" 'true' and 'false', then what
stops someone from defining

  #define true 1
  #define false 0

(leaving aside the perverse case of actually reversing the values).
Unlike when playing with other keywords, this one causes none but the most
subtle bugs ("cout << true;", etc.).

If the real reason is that no one wants to touch the preprocessor, please
say that.  I don't think there is an abstract reason that the preprocessor
should not handle

  #define WANT_FOO true
  #define WANT_BAR false

  #if (WANT_FOO)
  ...
  #endif

  #if (WANT_BAR)
  ...
  #endif



robt
--
Robert Mollitor            robert@visix.com
Visix Software Inc.     ...!uupsi!visix!robert
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

Distribution:
In <ROBERT.95Aug21123621@mirage.visix.com>, robert@Visix.COM (Robert Mollitor) writes:
>But if the preprocessor doesn't "understand" 'true' and 'false', then what
>stops someone from defining
>
>  #define true 1
>  #define false 0

That does not work correctly because if you have a function...

   void foo(bool);
   void foo(int);

and you call...

   foo(true)

the wrong function will be called.

Michael Lee Finney



---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

Distribution:
Excerpts from netnews.comp.std.c++: 22-Aug-95 Re: true/false literal std
.. vinoski@apollo.hp.com (1339)

> Also, if true and false were reduced to 1 and 0 by the preprocessor,
> overloading on type bool would not be possible.  I thought that
> overloading was a big reason that bool was added to the language in
> the first place.

I would expect that if the preprocessor were enhanced to recognize
true/false it would only do so in the context of #if, or #elif.  I think
the potential for confusion arising from the use of 1/0 for true/false
in the preprocessor and true/false in C++ code warrants fixing the
preprocessor to maintain consistency. It seems it would be fairly
trivial to add two new literals named true and false to the
preprocessor's expression parser...

-Rob

---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

Distribution:
In article <417kfc$1q3@engnews2.Eng.Sun.COM> Steve Clamage writes:
>If true and false were introduced into the preprocessor, they would
>have to be predefined to the preprocessor numbers 1 and 0. They would
>then be the only prefined literals in the preprocessor. Why would this
>be superior to just using 1 and 0 in your code, given that there are
>no types to begin with? That is, IMHO 'true' gives no advantage
>whatever over '1' in a preprocessor expression, since it cannot mean
>anything different from '1', and since it must iteract with expressions
>with integer (not boolean) values.

Also, if true and false were reduced to 1 and 0 by the preprocessor,
overloading on type bool would not be possible.  I thought that
overloading was a big reason that bool was added to the language in
the first place.

--steve

Steve Vinoski  vinoski@ch.hp.com        (508)436-5904
Distributed Object Computing Program    fax: (508)436-5122
Hewlett-Packard, Chelmsford, MA 01824

Standard Disclaimer:
All opinions expressed are my own and do not represent
official statements of the Hewlett-Packard Company.

---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

The draft standard introduces two new reserved identifiers -- "true" and "false"
(among others, of course).  These play the role of literals for the new bool type.

My question, is: are these new literals supported by the preprocessor?  The new
bool type is designed to replace the many variants of "boolean", "true" and
"false" found everywhere.  However many, if not most, of the existing
definitions can be used in preprocessor expressions.  If it is NOT possible to use
the new true/false literals in preprocessor expressions then they will have to
be duplicated just for preprocessing -- obviously not desirable.

Does anyone know the answer to this question?  Thanks.

Michael Lee Finney

In article qnk@mujibur.inmind.com, mfinney@inmind.com writes:
>The draft standard introduces two new reserved identifiers -- "true" and "false"
>(among others, of course).  These play the role of literals for the new bool type.
>
>My question, is: are these new literals supported by the preprocessor?  The new
>bool type is designed to replace the many variants of "boolean", "true" and
>"false" found everywhere.  However many, if not most, of the existing
>definitions can be used in preprocessor expressions.  If it is NOT possible to use
>the new true/false literals in preprocessor expressions then they will have to
>be duplicated just for preprocessing -- obviously not desirable.

They are language keywords, and are not interpreted by the preprocessor.
Just as you do not have 'int', 'char', or 'double' in the preprocessor,
you do not have 'bool' either. 'true' and 'false' are not aliases for 1
and 0, they are literals of type bool.

There are no types in the preprocessor; everything is a long integer.

You could #define something other than 'true' and 'false' (e.g. True, False)
to have the values 1 and 0 if you want, or you could just use the built-in
zero/not-zero dichotomy.

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