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-12-04 13:06:08

On Sun, Dec 2, 2012 at 8:23 PM, Edward Diener <eldiener_at_[hidden]>wrote:

> On 12/2/2012 3:47 PM, Andrey Semashev wrote:
>
>> On December 3, 2012 12:10:38 AM "Jeffrey Lee Hellrung, Jr."
>> <jeffrey.hellrung_at_[hidden]> 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.
>

There's nothing wrong with macros; just like everything in C++, they can be
used to great benefit and abused to great...the opposite of benefit.

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

Yeah, sorry Andrey, this only serves to reinforce my hesitation toward
injecting identifiers into the global namespace :)

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

I sympathize with this. I just prefer to be conservative if the costs are
not great. I think this is where we disagree.

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

Well I guess unless anyone speaks up opposed to globally injecting nullptr
into the global namespace, that's what I'll do (as I'm outvoted :)
Conditional on non-definition of a macro, of course.

- Jeff