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

Subject: Re: [boost] [config] Macro for null pointer
From: Edward Diener (eldiener_at_[hidden])
Date: 2012-12-02 23:23:51

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.

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