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

Subject: Re: [boost] std::auto_ptr in public interfaces
From: Stephan T. Lavavej (stl_at_[hidden])
Date: 2017-05-20 18:10:15

[Robert Ramey]
> We already BOOST_NO_AUTO_PTR have as part of config.hpp .  It was
> originally defined to address C++03 libraries that didn't included it. 
> The implementation could easily (I presume, since I'm not the person
> who is going to do it) be extended so that it is defined for C++11+ 
> conforming compilers.

MSVC's documented (since I say so) macro to control/report auto_ptr's availability is _HAS_AUTO_PTR_ETC which is defined to be either 0 or 1 (and you just have to include any STL header, e.g. good old <ciso646>).

Additionally, in VC 2017's second toolset update (not the first one that's being released soon), I am planning to aggressively warn about C++17's deprecated features in C++17 mode (/std:c++17 or /std:c++latest). All of the library stuff in Annex D will emit warnings, except for the <meow.h> C headers (it's silly that they're deprecated). (I can't warn about <codecvt> at the moment due to a compiler bug, but hopefully that'll be fixed so I can add those warnings.) This is going to be pretty noisy, but it'll ultimately make migrating code to C++20 and beyond easier.

I plan to have a system of fine-grained escape hatch macros, and a big "silence all C++17 deprecation warnings" macro, but libraries like Boost will need to avoid the deprecated components (or locally suppress C4996) since they don't really control the user's preferences.

Auditing Boost right now for unnecessary use of the Annex D stuff would be a good idea. Stuff like std::iterator, the old allocator members, and std::result_of are probably commonly used.

STL