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

Subject: Re: [boost] std::auto_ptr in public interfaces
From: Edward Diener (eldiener_at_[hidden])
Date: 2017-05-22 16:21:36

On 5/20/2017 10:30 AM, 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?

If config has a BOOST_NO_AUTO_PTR the locale and ptr_container libraries 
need to check that and provide an alternative implementation instead.

> 
> Ciao
>     Dani
> 
> ¹ algorithm, asio, assign, bimap, container, gil, graph, icl,
> interprocess, intrusive, lockfree, msm, phoenix, polygon, random, range,
> regex, statechart, test, typeof, wave, xpressive
>