Re: [boost] std::auto_ptr in public interfaces

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:
> 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