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: Jookia (166291_at_[hidden])
Date: 2012-08-24 05:10:51

On 24/08/12 19:09, Mathias Gaunard wrote:
> On 24/08/2012 01:09, Joel de Guzman wrote:
>> On 8/24/12 1:58 AM, Eric Niebler wrote:
>>> On 8/23/2012 1:42 PM, Jeff Flinn wrote:
>>>> Might it not be better to provide some platform specific config file(s)
>>>> that undef offending macro names. In the case of nil in fusion, I'd
>>>> hate
>>>> to see a loss in clarity because of some bad platform practice. I've
>>>> been able to address these issues by #undef'ing in just a few places.
>>>
>>> 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
>
> Name it nil_, and if 'nil' is not defined, provide a typedef named nil
> as well.

Would namespaces help in any way?