On Wed, Dec 5, 2012 at 4:43 AM, Andrey Semashev <andrey.semashev@gmail.com>wrote:
On December 5, 2012 3:32:05 PM Felipe Magno de Almeida < felipe.m.almeida@gmail.com> wrote:
On Wed, Dec 5, 2012 at 5:22 AM, Andrey Semashev <andrey.semashev@gmail.com> wrote:
On Wed, Dec 5, 2012 at 11:13 AM, Eric Niebler <eric@boostpro.com> 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 think the argument is that it's inconvenient when things do break. Much more inconvenient (and potentially less obvious to diagnose) than the inconvenience associated with requiring the user to explicitly bring the nullptr identifier into their desired use scope each time (which, IMHO, is not so bad). When you determine that you now need to disable the global nullptr using declaration that Boost provides, the situation could potentially require you to fix up all your nullptr uses to ensure you have a BOOST_USING_NULLPTR declaration in the proper scopes (e.g., header X begins to use library Y, which (perhaps irresponsibly) provides a ::nullptr that conflicts with Boost's, so now everything that directly or indirectly includes header X and uses nullptr needs a BOOST_USING_NULLPTR => PITA). - Jeff