Boost logo

Boost :

Subject: Re: [boost] [config] Macro for null pointer
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2012-11-29 03:04:43

On Thu, Nov 29, 2012 at 11:47 AM, Jeffrey Lee Hellrung, Jr.
<jeffrey.hellrung_at_[hidden]> wrote:
> Or even Boost code that may not be residing in the boost namespace. In any
> case, are you suggesting such code should have something along the lines of
> namespace X
> {
> #if !defined( BOOST_NO_CXX11_NULLPTR ) && !defined( BOOST_NO_GLOBAL_NULLPTR
> )

No, it's

#if defined( BOOST_NO_CXX11_NULLPTR )

> using boost::nullptr;
> #endif
> }
> ?
> That doesn't seem to be much of an improvement over a using macro :/
> Actually...I'd go so far as to say it's objectively worse than a using
> macro.

Well, we could provide the using macro as well, although I don't think
it's significantly better than the above. My main point is that
nullptr should "just work" (tm) by default.

> Note that Boost code residing in the boost namespace wouldn't need to
> qualify nullptr regardless of the presence/absence of the using
> declaration, so this is just concerns code outside the boost namespace
> which wishes to use the nullptr identifier.

That's right.

> There is no such problem with user's code as long as multiple
>> libraries /don't/ try to emulate global nullptr. If that happens you just
>> disable all emulations but one. nullptr is still there, nothing
>> breaks.
> Mildly annoying; and you hope all (or, at least, all but one) such emulated
> global nullptr's are responsible enough to have such a configuration macro
> :/ Strikes me as somewhat fragile.

Put it another way, are there any other emulations available yet? At
this point the argument is mostly theoretical. And Boost will provide
a way to disable its own global nullptr. If another library implements
global nullptr that is inferior in some way and cannot be disabled,
one has to pester that lib developers, not Boost.

Boost list run by bdawes at, gregod at, cpdaniel at, john at