🚀 go-pugleaf

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