🚀 go-pugleaf

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


-- 
Ajay Kamdar                               Email: ajay@lehman.com   
Lehman Brothers                           Phone: (201) 524-5048 

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