Boost logo

Boost :

Subject: [boost] std::auto_ptr in public interfaces
From: Daniela Engert (dani_at_[hidden])
Date: 2017-05-20 14:30:12

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?


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

PGP/GPG: 2CCB 3ECB 0954 5CD3 B0DB 6AA0 BA03 56A1 2C4638C5

Boost list run by bdawes at, gregod at, cpdaniel at, john at