Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk