Andrey Semashev wrote:
Felipe Magno de Almeida wrote:
Andrey Semashev wrote:
Eric Niebler wrote:
[snip]
... and Microsoft's min/max macros cause no problems because they can be disabled with NOMINMAX. :-P
I don't see how this is related. We're not making nullptr a macro, it still obeys scoping rules.
If it is global, then it is all scopes. And it can't even be qualified, because nullptr is never used qualified in user code.
I find reiterating myself. Yes, it is global but it's not a macro. The global using declaration is optional and can be disabled if there's another global nullptr available (a very slim probability). Other than the global import, it does not conflict with any other implementation (i.e. in another scope).
So, is there a use case that is broken with this approach that I'm missing?
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? I wonder if it wouldn't be better to have something like the following: namespace boost { namespace detail { class nullptr_t {...}; } #ifdef BOOST_CXX11_NO_NULLPTR typedef boost::detail::nullptr_t nullptr_t; #else typedef std::nullptr_t nullptr_t; #endif namespace { const boost::detail::nullptr_t nullptr_ = {}; } }//end boost And user code would use boost::nullptr_ of type boost::nullptr_t. It's not as nice as using straight nullptr, but I think it will interoperate better, since we're not constrained to suggest using it unqualified due to the nullptr keyword. Nate