|
Boost : |
Subject: Re: [boost] [config] Macro for null pointer
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2012-11-29 13:40:26
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? 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.
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.
Vicente
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk