🚀 go-pugleaf

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

In <4135i2$744@engnews2.Eng.Sun.COM>, clamage@Eng.Sun.COM (Steve Clamage) writes:
>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.  

Steve, 'int', 'char', 'double' and 'bool' are types and quite properly
the preprocessor knows nothing about them.

However, '0', '1', 'true' and 'false' are NOT types, they are literals and
therefore SHOULD be recognized by the preprocessor.  It would be very
annoying to have the committee fix the "boolean" problem -- and then
make us do the same thing all over again for the preprocessor.


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. ]

In article <MATT.95Aug22012318@Austern> mfinney@inmind.com writes:
>
> 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.
>

I'm sorry.  I was too cryptic.  I agree with you that it is a bad thing
for the reason you mention.  I would expect a C++ preprocessor to disallow
the #defines in the first place (as it maybe should disallow #defines to
any keyword?).  If this is a C incompatibility issue, so be it.

  #ifndef __cplusplus
  #define true 1
  #define false 0
  #endif

is easy enough.


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. ]