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