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

Subject: Re: [boost] std::auto_ptr in public interfaces
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2017-05-22 23:56:47

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.