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