On 12/2/2012 3:47 PM, Andrey Semashev wrote:
On December 3, 2012 12:10:38 AM "Jeffrey Lee Hellrung, Jr." <jeffrey.hellrung@gmail.com> wrote:
Well either way, I reiterate my comment: If we have a conditional global-scope using declaration, I would imagine we would strongly recommend that client code likewise include a conditional using declaration (whether wrapped in a macro or explicitly expressed via #ifndef...#endif) so that things continue to "just work" whether the global-scope using declaration is enabled or not.
Why would I need the using declaration in my (user's) code if it's already provided by Boost header? I'm in control of my code, I know there are no conflicts and I do not disable the global nullptr provided by Boost. IMHO, you're trying to solve the problem that isn't there.
On the other hand, requiring a user to just have a "BOOST_USING_NULLPTR;" declaration at the scope they wish to use the nullptr identifier seems safer (Boost doesn't inject anything into the global scope) and simpler / more uniform (no need for an additional configuration macro and explanation for why it's necessary and when one needs to concern oneself with it).
I don't like macros. And for a small tool like nullptr including a header is just about as much as I would bother doing to get it. If I have to put BOOST_USING_NULLPTR in every place I intend to use nullptr I will probably be lazy enough to just continue using NULL.
I do like macros but I agree with what you say above from a usability point of view.
I would only recommend BOOST_USING_NULLPTR (or explicit conditional using declaration) to library writers, to avoid conflicts with other libraries.
PS: And Boost does inject things into global scope already. At least _1, _2... come to mind.
That is a mistake that should not have been made and has been the subject of numerous posts already when conflicts occured between various libraries using the _1, _2 notation. But I do agree with you in this case that specifying 'nullptr' should just work without the end-user having to do anything but include a boost header file, which supports the Boost 'nullptr' implementation. The reason I feel this way in the current situation is because 'nullptr' as a C++ keyword and therefore is 'global' to everything. Once the correct header is included the Boost nullptr should be as transparently as possible like the C++ 'nullptr' without the user having to do anything more. A macro should be created to turn off the use of the Boost nullptr as a substitute for the C++ 'nullptr' when the C++ implementation does not support the 'nullptr' keyword.