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

Subject: Re: [boost] [config] Macro for null pointer
From: Edward Diener (eldiener_at_[hidden])
Date: 2012-12-04 17:46:17

On 12/4/2012 3:19 PM, Eric Niebler wrote:
> On 12/4/2012 12:05 PM, Edward Diener wrote:
>> On 12/4/2012 1:10 PM, Eric Niebler wrote:
>>> On 12/4/2012 10:06 AM, Jeffrey Lee Hellrung, Jr. wrote:
>>>> 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.
>>>
>>> Please, no. The bind placeholders are bad enough.
>>
>> The use of 'nullptr' is "global" in C++. Why should not the inclusion of
>> a particular Boost header file, possibly emulating 'nullptr' for
>> compilers that do not support it, also create a "global" 'nullptr'.
>>
>> I totally agree that normally injecting anything into the global
>> namespace is a very poor thing to do. But in this case we would be
>> emulating something that is already "global" by the C++ standard.
>>
>> The idea I believe is this: the end-user includes the Boost header file.
>> If there is already an implementation of 'nullptr' for the particular
>> C++ compiler beng used, absolutely nothing in the header file does
>> anything. If there is not an implementation of 'nullptr' for the
>> particular C++ compiler beng used, the end-user's use of 'nullptr' in
>> his code is using the Boost implementation.
>>
>> Expecting an end-user to both include the Boost header file and then
>> somehow know or care whether or not his compiler supports 'nullptr' and
>> do something more when it does not before he can use 'nullptr' in his
>> code, seems to me to defeat the purpose of providing a nullptr emulation.
>
>
> ... until some other library ALSO defines a global nullptr symbol,
> making that library and boost mutually incompatible.

I doubt that the case will occur very often.

But in that case the end-user will have to choose which nullptr 
emulation to use. If he chooses the other library's emulation he does 
not include the Boost header file for nullptr emulation, and vice-versa.

Anything more complicated than that, where he wants to choose which 
nullptr implemenetation to use after including both library's header 
files, is utterly unrealistic to me.