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: https://github.com/boostorg/ptr_container/pull/8
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
Nice.
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 implement 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) kind regards Thorsten