🚀 go-pugleaf

: What's so wrong with saying what you mean:
:  
:     #ifndef USE_ORIGINAL_UNHACKED_CODE
:         hack(); hack(); hack();
:     #else
:         // This code disabled because
:         ...
:     #endif
:  
: The point is why change the language to support your idiosyncacies?

Right now #if 0 /#if 1 is supported.

What about code that you'd expect to work:

#define USE_FEATURE_FOO true

#if USE_FEATURE_FOO
	/* This code isn't included */
#endif

Whereas,

#define USE_FEATURE_FOO 1

#if USE_FEATURE_FOO
	/* This code is included */
#endif

That's why the preprocessor should know about true/false.  It should
not expand them into 1/0, but rather it should accept them in the
context of #if expressions as 1.

Here's a case where #if true would happen, given the macro expansion
of USE_FEATURE_FOO.  I think therefore it is useful.  Otherwise, there
will be many hard to find bugs until people get burned by this.

Unfortunately, this change would make the preprocessor part of the
language different than ANSI-C.

	[ The C++ preprocessor is already quite different to C-89:
	  it has new keywords, "//" comments, and digraphs.
	  So I don't really understand the reluctance to modify
	  the preprocessor. 
		-fjh (moderator).
	]

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