On December 5, 2012 10:50:41 PM Eric Niebler <eric@boostpro.com> 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.