On Wed, Jan 2, 2013 at 9:49 AM, Peter Dimov <lists@pdimov.com> wrote:
Daniel James wrote:
On 19 December 2012 04:47, Eric Niebler <eric@boostpro.com> 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