Boost logo

Boost :

Subject: Re: [boost] [config] Macro for null pointer
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2012-11-29 12:51:54


On Thu, Nov 29, 2012 at 12:04 AM, Andrey Semashev <andrey.semashev_at_[hidden]
> wrote:

> 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 )
>

Yes, you're correct.

> > 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.

BOOST_USING_NULLPTR;

Looks better to me :/ How much better is subjective.

My main point is that
> nullptr should "just work" (tm) by default.
>

But, it kinda doesn't "just work" if correct and robust use requires a
conditional using declaration. And, at that point, what use is the "using
boost::nullptr" at global scope anyway, if it's conditional on a
configuration macro?

> 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.
>

True.

- Jeff


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