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

Subject: Re: [boost] std::auto_ptr in public interfaces
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2017-05-20 15:28:54

On 05/20/17 17:30, Daniela Engert via Boost wrote:
> Hi everybody,
> 
> you are probably aware of the fact that the upcoming C++17 standard is
> going to remove std:auto_ptr (and other deprecated features), and that
> MSVC 14.0 and 14.1 no longer supply these deprecated, to-be-removed
> features when compiling in a 'later than C++14' mode (i.e.
> /std::c++latest or /std:c++17). Today I've learned that latest versions
> of libc++ also no longer supply std::auto_ptr when compiled in C++17
> mode. Some time ago I've talked about an in-house version of Boost which
> no longer requires these deprecated features and builds and passes tests
> in C++17 mode. As of yesterday I've completed my  pull-requests against
> all those libraries using any of these features (¹), to deal with this
> situation where required - except for two libraries: locale and
> ptr_container. These two remaining libraries use std::auto_ptr in their
> public interfaces and replacing std::auto_ptr with std::unique_ptr is
> not as easy as a replacement of std::auto_ptr used in the bowels of a
> library or in test code. It would impose respective changes to user code
> as well. In our company we just got rid of all traces of std::auto_ptr
> and happily keep on using locale and ptr_container just as before. So
> guys, what's your opinion of how to deal with this situation?

Here is a reply of Boost.Locale developer to a similar question from me:

https://lists.boost.org/Archives/boost/2015/11/226475.php

Personally, I would prefer libraries to switch to boost::unique_ptr and 
leave std::auto_ptr interfaces available (but deprecated) for backward 
compatibility. But I'm not a maintainer of either of the libraries in 
question.