🚀 go-pugleaf

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