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-11-30 01:57:12

On Thu, Nov 29, 2012 at 10:40 AM, Vicente J. Botet Escriba <
vicente.botet_at_[hidden]> wrote:

> Le 29/11/12 08:23, Jeffrey Lee Hellrung, Jr. a écrit :
>
>> On Wed, Nov 28, 2012 at 11:15 PM, Andrey Semashev <
>> andrey.semashev_at_[hidden]
>>
>>> wrote:
>>> On Wed, Nov 28, 2012 at 8:43 PM, Jeffrey Lee Hellrung, Jr.
>>> <jeffrey.hellrung_at_[hidden]> wrote:
>>>
>>>> using boost::nullptr;
>>>>>
>>>>>  One thing I wonder about is if this using declaration is The Right
>>>> Thing
>>>>
>>> To
>>>
>>>> Do. An alternative is to provide a macro to bring the nullptr identifier
>>>> into the current scope (and which does nothing in C++11).
>>>>
>>> I don't like the macro with using declaration. I'd rather have this
>>> using declaration in the header, with possibility to disable it by
>>> defining a config macro:
>>>
>>> #ifndef BOOST_NO_GLOBAL_NULLPTR
>>> using boost::nullptr;
>>> #endif
>>>
>>> And I want this declaration to be enabled by default since the
>>> language keyword is not scoped in a namespace and that's what we try
>>> to emulate. The macro switch is only there to solve problems if they
>>> arise.
>>>
>>>  Eh I don't think it's a good idea to control scope via a configuration
>> macro. Anything that uses it unqualified (and which you have no control
>> over) would suddenly break upon disabling the using declaration.
>>
>
> How the using declaration would help if a 3pp library provides already
> nullptr in the global namespace?

The using declaration above is presumed to reside in some namespace or
function.

> This will be ambiguous, isn't it?
>
>>
>> In bringing this up, I'm thinking of the case in which some other 3rd
>> party
>> decided that they, too, wanted to provide a nullptr emulation, so now we
>> have 2 conflicting nullptr identifiers at global scope. That makes Boost
>> and this 3rd party library unusable together.
>>
>>
>>  The macro to disable the using declaration makes them usable together,
> but the problem is that now code that was using the bool emulation will use
> the 3pp one.
>

Actually, yeah, that could be problematic...

> I don't think there is a global solution to this problem. I think that the
> library should provide the using declaration by default so a user that
> knows that his application would not have any 3pp trouble could use the
> unqualified nullptr. Unfortunately libraries authors including Boost
> libraries should use nullptr qualified as ::boost::nullptr to avoid any
> possible conflicts.
>

Well, I don't know if that's possible, as ::boost::nullptr would probably
trigger a compiler error when the real nullptr is present.

I'm leaning toward being conservative and just provide a using macro. Then
one only has to state the macro once within each file they use nullptr
(doesn't seem like that big a deal) and they can use it unqualified
thereafter. If the using declaration is anywhere except global scope, there
shouldn't ever be conflicts from any other (reasonable) nullptr emulations.
E.g., use would be something like

namespace X
{

BOOST_USING_NULLPTR;

void f() { int * p = nullptr; }

} // namespace X

- Jeff