Boost logo

Boost :

Subject: Re: [boost] What to do with platform defining 'null' as preprocessor symbol?
From: Jeff Flinn (Jeffrey.Flinn_at_[hidden])
Date: 2012-08-24 08:44:20

On 8/23/2012 7:09 PM, 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:

Searching the dozens of Mac Frameworks used in our projects, I get two
hits for 'nil':

- objc.h

#ifndef nil
#define nil __DARWIN_NULL


- MacTypes.h

#ifndef nil
#define nil NULL

We have a pretty large and old code base whose 'nil' usage, is well
nil;-). So as I've mentioned to Joel before, I'd hate to see time spent
on modifying fusion use of 'nil'. Using BOOST_PREVENT_MACRO_SUBSTITUTION
certainly doesn't help with code clarity, and I've not checked if it
works with names beyond function names: types, variables, arguments, ...


Boost list run by bdawes at, gregod at, cpdaniel at, john at