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: Jan Hudec (bulb_at_[hidden])
Date: 2012-08-24 14:17:52

On Thu, Aug 23, 2012 at 22:09:06 +0400, Andrey Semashev wrote:
> On Aug 23, 2012 9:59 PM, "Eric Niebler" <eric_at_[hidden]> 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.

Anybody using boost is probably used to reasonable C++ practices and uses
'NULL' or 'nullptr' and not funky platform-specific nonsense like 'null'.

So from this point of view I'd be more inclined to undefining it or erroring
out if it's defined and let the under undefine it by hand (well, any
reasonable user will IMHO do it in user_config.hpp anyway).

> Perhaps, pragmas like push/pop_macro could help on compilers that support
> it?

Unfortunately I don't think gcc 4.5.0 does.

-- 
						 Jan 'Bulb' Hudec <bulb_at_[hidden]>