Boost logo

Boost :

Subject: Re: [boost] std::auto_ptr in public interfaces
From: Robert Ramey (ramey_at_[hidden])
Date: 2017-05-21 16:55:04


On 5/20/17 11:06 PM, Daniela Engert via Boost wrote:
> Am 20.05.2017 um 19:46 schrieb Robert Ramey via Boost:
>> On 5/20/17 10:18 AM, Richard Hodges via Boost wrote:
>>
>>> unless I specifically request it by defining the preprocess or symbol
>>> BOOST_ALLOW_AUTO_PTR or some such.
>>
>> 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.
>
> 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').

I didn't know this.

> 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.

I didn't know this either
>
> 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.
>
> What do you think?

Sounds like we're done. I guess great minds think alike.
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk