🚀 go-pugleaf

mfinney@inmind.com wrote:
>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

That's what Steve said.

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

In the preprocessor they would just end up being aliases for 0 and 1 anyway, 
so you're exactly as far ahead to just '#define True 1' as Steve pointed out.

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.

Regards,

Herb


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