🚀 go-pugleaf

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.  Nor does 'true' need to be interpreted as a "type" of bool.

A literal is a special symbol that the compiler recognizes as a constant.
The preprocessor handles some literals (such as numbers and characters),
but not others (such as floating point numbers).  I believe that the
'true' and 'false' literals SHOULD be recognized by the preprocessor
becuase they promote to intergral types and can therefore be used in a
constant integral expression.

I personally find it very annoying to use 'true' in one location and 'True'
or 'TRUE' or 'tRUe' somewhere else -- differing only in capitalization but
having the same intent and semantic definition.  This is absolutely (in my
opinion) unnecessary confusion that such a situation would engender.  And
it would ALSO tend to promote bugs.  The preprocessor would bitch if 'true'
were used, but the compiler would NOT bitch if 'True' were used because
of the standard promotion rules.

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