Boost logo

Boost :

Subject: Re: [boost] [config] Macro for null pointer
From: Eric Niebler (eric_at_[hidden])
Date: 2012-12-04 15:19:36


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.

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com

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