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

Subject: Re: [boost] [config] Macro for null pointer
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2012-12-05 13:15:23

On Wed, Dec 5, 2012 at 4:43 AM, Andrey Semashev
<andrey.semashev_at_[hidden]>wrote:

> On December 5, 2012 3:32:05 PM Felipe Magno de Almeida <
> felipe.m.almeida_at_[hidden]> wrote:
>
>> On Wed, Dec 5, 2012 at 5:22 AM, Andrey Semashev
>> <andrey.semashev_at_[hidden]> wrote:
>> > On Wed, Dec 5, 2012 at 11:13 AM, Eric Niebler <eric_at_[hidden]>
>> 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