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

Subject: Re: [boost] [config] Macro for null pointer
From: Nathan Crookston (nathan.crookston_at_[hidden])
Date: 2012-12-05 11:59:58

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