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
> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk