On 21/05/2017 18:06, Daniela Engert wrote:
Robert, BOOST_NO_AUTO_PTR has already acquired the (additional) semantic of 'std::auto_ptr is no longer available' (have a peek at boost_macro_reference.html, section 'macros that describe features that have been removed from the standard'). A few libraries use this macro now to switch between std::auto_ptr and std::unique_ptr for their RAII holders, both in their non-public internal parts and in their test code.
So, libraries with std::auto_ptr in their public interface might implement both std::auto_ptr-based functions and std::unique_ptr-based functions in parallel, guarded by BOOST_NO_AUTO_PTR or BOOST_NO_CXX11_SMART_PTR.
There's already some examples of this in existing Boost code; one of the most obvious is boost/get_pointer.hpp, which provides std::auto_ptr overloads unless BOOST_NO_AUTO_PTR is defined, and std::unique_ptr and std::shared_ptr overloads unless BOOST_NO_CXX11_SMART_PTR is defined. 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. It's a little trickier for implementation details; there it's probably best to always use std::unique_ptr, unless BOOST_NO_CXX11_SMART_PTR is defined. Fortunately nobody should be returning an auto_ptr by reference, so that shouldn't cause any problems for the interface.