Subject: Re: [boost] [smart_ptr] error with nullptr_t
From: John Bytheway (jbytheway+boost_at_[hidden])
Date: 2012-12-11 21:21:50
On 11/12/12 14:47, Peter Dimov wrote:
> Vicente J. Botet Escriba wrote:
>> Hi,
>>
>> next follows a compile error with clang 3.1 c++11 just including
>>
>> #include <boost/shared_ptr.hpp>
>>
>> iMac-de-Vicente-Botet-Escriba:test viboes$ time bjam
>> toolset=clang-3.1x ts_ -q
>> ...patience...
>> ...found 1100 targets...
>> ...updating 50 targets...
>> clang-darwin.compile.c++
>> ../../../bin.v2/libs/thread/test/test_so.test/clang-darwin-3.1x/debug/threading-multi/test_so.o
>>
>> In file included from ../example/test_so.cpp:6:
>> In file included from ../../../boost/shared_ptr.hpp:17:
>> ../../../boost/smart_ptr/shared_ptr.hpp:344:22: error: non-friend
>> class member 'nullptr_t' cannot have a qualified name
>> shared_ptr( std::nullptr_t ) BOOST_NOEXCEPT : px( 0 ), pn() //
>> never throws
>> ~~~~~^
>
> This is probably another manifestation of the issue with clang
> supporting the c++11 core language, but the libstdc++ not supporting it,
> namely, <ctsddef> not defining nullptr_t. I'm not sure how to fix that.
> !defined(BOOST_NO_CXX11_NULLPTR) does, in my opinion, imply that
> std::nullptr_t is present (along with nullptr itself). It's not clear
> how a library could offer nullptr support without using nullptr_t.
I believe std::nullptr_t could be replaced with decltype(nullptr), which
would allow this support to be offered without standard library assistance.
John Bytheway