Re: [boost] What to do with platform defining 'null' as preprocessor symbol?

Subject: Re: [boost] What to do with platform defining 'null' as preprocessor symbol?
From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2012-08-24 08:25:32

On Fri, 24 Aug 2012 07:09:35 +0800, Joel de Guzman wrote:

> On 8/24/12 1:58 AM, Eric Niebler wrote:

>> Bad idea, IMO. Boost shouldn't be messing with things defined in 3rd
>> party headers, especially platform headers. #including a boost header
>> shouldn't change the meaning of existing code, or make valid platform
>> code invalid. The same reason went into the Boost min/max guidelines
>> and Herculean effort to bring our codebase into compliance with them.
> 
> It's been a long standing issue that I can't seem to find a resolution
> for: Fusion's use of nil. What can we do about it? Nothing? Do we just
> let the user deal with it themselves (e.g. by #undef'ing). I am somehow
> being compelled to succumb to the pressure. Mac folks have been pleading
> for years now to rename struct nil to something else. Unfortunately,
> it's part of the API: http://tinyurl.com/c3k7fgw

I would just use

#define nil nil

as a sanity check and call it done.  If the symbol is already defined, 
compilation error (or at least warning on overly permissive compilers).  
The symbol will be need to be undefined in between the inclusion of the 
two libraries.

Workarounds like nil_ and (min)(...) just perpetuate the problem.  Fix the 
root problem rather than treating the symptom indefinitely.  Otherwise, 
where is the line drawn?  Even if you can't provide a transparent fix 
(such as defining nil as a constant and min/max as functions), the 
backwards compatibility argument fails in the long run.  The amount of 
effort required to make the necessary changes to existing code will 
eventually be outweighed by the effort to implement workarounds put into 
new code (as well as educate everyone that they are necessary)--especially 
in cases like these which can mostly be emulated in a way that causes most 
existing code to work.

Regards,
Paul Mensonides