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-18 17:03:54

On Sun, Nov 18, 2012 at 7:22 AM, Edward Diener <eldiener_at_[hidden]>wrote:

> On 11/16/2012 12:32 AM, Jeffrey Lee Hellrung, Jr. wrote:
>
>> On Thu, Nov 15, 2012 at 7:04 PM, Edward Diener <eldiener_at_[hidden]>*
>> *wrote:
>>
>>  I have found something like this to be helpful, when working with
>>> multiple
>>> compilers:
>>>
>>> #include <boost/config.hpp>
>>> #if defined(BOOST_NO_NULLPTR)
>>> #define BOOST_XXX_NULLPTR 0
>>> #else
>>> #define BOOST_XXX_NULLPTR nullptr
>>> #endif
>>>
>>> where XXX is some local name for my own use. And then use
>>> BOOST_XXX_NULLPTR in places where a null pointer is needed.
>>>
>>> Would this be a candidate for a BOOST_NULLPTR macro in the config library
>>> instead ?
>>>
>>>
>> Might it be better to just offer a (albeit imperfect) nullptr emulation if
>> not supplied by the compiler? For example, [1].
>>
>> - Jeff
>>
>> [1] http://en.wikibooks.org/wiki/**More_C%2B%2B_Idioms/nullptr
>

>>
>
> I agree that you are right.
>
> If the nullptr emulation has less problems than using 0 it would seem
> worthwhile. That appears to be easily the case. Both are of course
> imperfect but it appears that a nullptr emulation is far less imperfect.
> The question then is who is going to do it and support it, given that it
> will most probably be obsolete in the near future as more compilers
> implement features of C++11. Unless someone steps up to do it ( and I am
> not that person due to, for one, already being behind in getting TTI into
> Boost ) it will not be done and then using 0 is at least a second best
> solution.
>
> In my own current use of nullptr in cross-compiler code for Boost using 0
> is adequate for my means in the few instances where I am using nullptr. So
> my suggestion in my OP is adequate for me right now but may well not be
> adequate for others or for future usage on compilers which do not support
> nullptr.
>

I'll post something this week and if it's ultimately decided to be included
in, e.g., boost/utility, I don't have a problem supporting it.

- Jeff