On Thu, Nov 29, 2012 at 12:04 AM, Andrey Semashev <andrey.semashev@gmail.com
wrote:
On Thu, Nov 29, 2012 at 11:47 AM, Jeffrey Lee Hellrung, Jr. <jeffrey.hellrung@gmail.com> 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