Subject: Re: [boost] std::auto_ptr in public interfaces
From: Thorsten Ottosen (tottosen_at_[hidden])
Date: 2017-05-23 14:54:19
Den 23-05-2017 kl. 16:36 skrev Daniela Engert via Boost:
> Am 23.05.2017 um 01:56 schrieb Gavin Lambert via Boost:
>> If anything else that currently uses std::auto_ptr in its public
>> interface does likewise, then everybody should be happy:
>> - those using C++98/03 compilers can continue using std::auto_ptr.
>> - those using C++11/14 compilers get both and their old code will
>> compile while allowing them to convert to std::unique_ptr at their
>> leisure. (The compiler should be giving them deprecation warnings, so
>> they know to do this.)
>> - those using C++17 compilers don't get the std::auto_ptr version,
>> which would no longer compile.
> There it is, my take on Boost.Ptr_container:
> This passes the testsuite just like vanilla develop when compiled with
> * msvc 9.0 which has no std::unique_ptr
> * msvc 14.x in a mode without std::auto_ptr
> * msvc 12.0 which has both std::auto_ptr and std::unique_ptr
> The std::auto_ptr-based library interface can be deliberately disabled,
> and similarly the std::auto_ptr-based tests.
> I'm all ears for suggestions, pointing out errors, whatever ...
A. so you pass unique_ptr<T> by value ... is that the preferred way
compared to unique_ptr<T>&& ?
B. I wouldn't provide unique_ptr versions for clone()/constructor, but
container( container&& ) = default;
container& operator=( container&& ) = default;
C. I would change auto_type to unique_ptr<T> for C++11 (or whatever
boost macro that says it is there)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk