🚀 go-pugleaf

In article <9508311315.ZM8754@jabba>, Ajay Kamdar <ajay@lehman.com> wrote:
>In article <809869855snz@ma.ccngroup.com>,
>Alan Griffiths  <aGriffiths@ma.ccngroup.com> wrote:
>>In article <9508310634.1386@mulga.cs.mu.OZ.AU>
>>           fjh@munta.cs.mu.OZ.AU "Fergus Henderson" writes:
>>
>>> "Brian T. Hill" <bhil@strata3d.com> writes:
>>>
>>> >Who wants to use "true" or "false" in the preprocessor anyway?
>>>
>>> I do.
>>>
>>>
>>>         #if 1
>>>                 // alert! this is a temporary hack!!
>>>                 hack(); hack(); hack();
>>>         #else
>>>                 // this code disabled because ...
>>>                 ...
>>>         #endif
>>
>>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?
>
>
>Another important advantage of using the descriptive preprocessor macro
>names is that it is a much easier and more flexible when there is a need
>to selectively turn on/off certain hacks.
>
>It is very rare that all the hacks and conditionals get turned
>on or off at the same time. Selectively controlling which hacks or
>conditional code gets compiled in is much easier when descriptive
>#if guards are used rather than #if 1 or #if true. And once you decide
>to use descriptive names, there is very little difference between:
>
>#define USE_ORIGINAL_UNHACKED_CODE 1
>#define WORK_AROUND_CTOR_BUG       0
>
>and
>
>#define USE_ORIGINAL_UNHACKED_CODE true
>#define WORK_AROUND_CTOR_BUG       false
>
>

	This is true so long as you only ever intend to use these
flags as switches to the preprocessor.   From time to time, cases 
arise when you want to define a flag that will be used both as a 
preprocessor switch and as a constant in ordinary code.  For example,
something like 

#define BIG_ENDIAN true

	If you define it as 

#define BIG_ENDIAN 1

	functions overloaded on both bool and int don't work properly
when they are applied to BIG_ENDIAN, but if you don't the preprocessor
mishandles #if BIG_ENDIAN.   

	The necessary fix to the preprocessor is relatively simple.
In the description of #if, there is a sentence: ``After all
replacements due to macro expansion and the |defined| unary operator
have been performed, all remaining identifiers are replaced with the
pp-number |0|.'' Rewording this as ``After all replacements due to
macro expansion and the defined unary operator have been performed,
all remaining instances of the identifier true are replaced with the
pp-number |1|, and all other remaining identifiers are replaced with
the pp-number |0|.''  fixes the problem.  This sort of klugey special
case seems entirely in keeping with the current design of the bool
type (e.g. the bizarre rules about ++ and --).

   	Otherwise, we're going to end up seeing an awful lot of
definitions of the form

	#define true (1||true) 

(or one of it's many moral equivalents) in people's header files, just
to be sure they don't get bitten by this problem.









--
William E. Aitken 			    | Formal verification is the 
email: aitken@halcyon.com                   |  future of computer science ---
Snail: 8500 148th Ave NE #H1026 Redmond WA  | Always has been, always will be.
===============================================================================

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