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

Subject: Re: [boost] std::auto_ptr in public interfaces
From: Daniela Engert (dani_at_[hidden])
Date: 2017-05-22 05:56:01

Am 21.05.2017 um 19:41 schrieb Daniel James via Boost:
> On 20 May 2017 at 17:29, Daniela Engert via Boost <boost_at_[hidden]> wrote:
>>
> 
> I don't think it's realistic to expect everyone to update their entire
> code base at once. Especially if they're using code from multiple
> sources. It should be as easy as possible to start using new versions,
> any friction can result in people getting stuck on old versions which
> makes life harder for everyone. If two dependencies both use the same
> boost library, then it's unlikely they'll both update simultaneously,
> so making it an either/or choice can cause real problems.
> 

I totally agree with you Daniel, but I'm not sure if we are on the same
page here. Andrey's proposal is to have the existing interface based on
std::auto-ptr side-by-side with a new one based on a future
boost::unique_ptr, deprecating the std::auto_ptr interface. My proposal
differs only in going to std::unique_ptr rather than boost::unique_ptr.

The rationale is that users affected by the removal of std::auto_ptr
from their standard libraries when in C++17 mode have std::unique_ptr
available anyway. There are multiple options to handle this situation,
but ignoring it is no option at all: unless you do at least *anything*
you can't compile code with std::auto_ptr in it, and you can't link to
code using it in it's interface. This is what I meant then talking about
the removal of std::auto_ptr affecting the whole codebase.

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