Re: [boost] [config] Macro for null pointer

Subject: Re: [boost] [config] Macro for null pointer
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2012-12-05 15:16:05

On December 5, 2012 10:50:41 PM Eric Niebler <eric_at_[hidden]> wrote:
> On 12/5/2012 8:59 AM, Nathan Crookston wrote:
> >
> > I would be concerned if I were using a library (A) which used boost.nullptr
> > and another library (B) which shipped its own, potentially at global scope.
> >
> > I can disable the global using declaration, but if library A is using it
> > unqualified, as suggested, then wouldn't I need to update that library's
> > code?  Or would they be required to check for the disabling macro?
>
> Precisely. Before boost had its min/max guidelines, we used to tell
> people to just compile with NOMINMAX when conflicts arose. Then we
> learned that some of Microsoft's own Platform SDK headers don't compile
> in that configuration. This situation can happen not just for macros but
> also for conditionally-defined global variables. Which is why I brought
> the example up.

Are you suggesting that Boost may not work when Boost's global nullptr 
is disabled? I find it unlikely to happen because unqualified nullptr 
from boost namespace will always bind to boost::nullptr regardless of 
the global using declaration. Even if it does happen somehow, we will fix it.

This may happen if a third-party lib doesn't use BOOST_USING_NULLPTR to 
import nullptr to its namespace and uses unqualified nullptr. That 
would be a bug in that library then.

> I for one will simply be using 0 in code that needs to be portable. I
> don't feel the need for anything fancier.
>
> I might consider using a BOOST_NULLPTR macro if it were defined like this:
>
> #if c++11 // <-- psuedo-code
> #define BOOST_NULLPTR nullptr
> #else
> #define BOOST_NULLPTR 0
> #endif

If the alternative is to always use BOOST_USING_NULLPTR, I would 
probably agree, except that I would use NULL instead of 0.