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

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

On Wed, Nov 28, 2012 at 11:32 PM, Andrey Semashev <andrey.semashev_at_[hidden]
> wrote:

> On Thu, Nov 29, 2012 at 11:23 AM, Jeffrey Lee Hellrung, Jr.
> <jeffrey.hellrung_at_[hidden]> wrote:
> > On Wed, Nov 28, 2012 at 11:15 PM, Andrey Semashev <
> andrey.semashev_at_[hidden]
> >> wrote:
> >
> >> On Wed, Nov 28, 2012 at 8:43 PM, Jeffrey Lee Hellrung, Jr.
> >> <jeffrey.hellrung_at_[hidden]> wrote:
> >> >>
> >> >> using boost::nullptr;
> >> >>
> >> >
> >> > One thing I wonder about is if this using declaration is The Right
> Thing
> >> To
> >> > Do. An alternative is to provide a macro to bring the nullptr
> identifier
> >> > into the current scope (and which does nothing in C++11).
> >>
> >> I don't like the macro with using declaration. I'd rather have this
> >> using declaration in the header, with possibility to disable it by
> >> defining a config macro:
> >>
> >> #ifndef BOOST_NO_GLOBAL_NULLPTR
> >> using boost::nullptr;
> >> #endif
> >>
> >> And I want this declaration to be enabled by default since the
> >> language keyword is not scoped in a namespace and that's what we try
> >> to emulate. The macro switch is only there to solve problems if they
> >> arise.
> >>
> >
> > Eh I don't think it's a good idea to control scope via a configuration
> > macro. Anything that uses it unqualified (and which you have no control
> > over) would suddenly break upon disabling the using declaration.
>
> You mean a third party library that relies on Boost emulation of
> nullptr? I think, the library has every mean to mitigate this problem
> (e.g. to check that nullptr is emulated and import it into its own
> namespace).
>

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

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.

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.

> > In bringing this up, I'm thinking of the case in which some other 3rd
> party
> > decided that they, too, wanted to provide a nullptr emulation, so now we
> > have 2 conflicting nullptr identifiers at global scope. That makes Boost
> > and this 3rd party library unusable together.
>
> That's exactly the reason the config macro is provided. Until such
> conflict appears one can safely use nullptr without qualification.
>

That would be ideal but, as I've explained above, I still have some
reservations about it.

- Jeff