Re: [boost] [smart_ptr] error with nullptr_t

Subject: Re: [boost] [smart_ptr] error with nullptr_t
From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2013-01-02 06:36:57

On Wed, Jan 2, 2013 at 9:49 AM, Peter Dimov <lists_at_[hidden]> wrote:
> Daniel James wrote:
>>
>> On 19 December 2012 04:47, Eric Niebler <eric_at_[hidden]> wrote:
>> > Regardless, (speaking as a release manager) I'd like to see this
>> > addressed one way or the other since it's a breaking change.
>>
>> What's the way forward?
>

Would there be a way to determine whether the user is using libstdc++
on the Mac from Boost.Config?

I distinctly remember that most standard Mac OS X installations come
with a frozen version of libstdc++ (GCC's 4.2) which has patches from
Apple. Apple's Clang I supports C++11 but only really works if you
link with libc++ (or maybe if you get an updated libstdc++ with
patches to work on OS X with clang). Being able to check the version
of libstdc++ being used should give you a better way of making this
determination.

>
> Assuming that we want to support this configuration, the options I see are
>
> - Config defining std::nullptr_t as it does with size_t;

I'm ambivalent about this FWIW.

> - Config defining BOOST_NO_NULLPTR_T, so that libraries can activate
> workarounds, or

This looks like the better situation.

> - SmartPtr fixing the problem somehow without Config involvement, which
> would entail detecting the problematic configuration in some way.
>

If the check for clang+libstdc++ can be localised in SmartPtr, this
would make sense but I think it's not going to be the only thing that
will run into this issue.

Just my A$0.05.

--
Dean Michael Berris
www.deanberris.com