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
>> that client code likewise include a conditional using declaration
>> 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
>> 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
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk