Boost logo

Boost :

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.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk