Re: std::auto_ptr deprecation (Was: [release] Boost 1.74.0 Release Candidate 1)

From: Jonathan Wakely (jwakely.boost_at_[hidden])
Date: 2020-08-21 11:27:19

On Tue, 11 Aug 2020 at 15:08, Jeff Garland via Boost <boost_at_[hidden]>
wrote:

> On Tue, Aug 11, 2020 at 6:52 AM Stefan Seefeld via Boost <
> boost_at_[hidden]> wrote:
>
> > Hi all,
> >
> > On 2020-08-11 9:41 a.m., Jeff Garland via Boost wrote:
> > > My compile report the RC:
> > >
> >
> > Does boost have a mechanism (compilation flags, auto-defined macro,
> > etc.) to mask `std::auto_ptr` usage ?
> >
> > Note that the situation isn't quite as simple as replacing
> > library-internal use of `std::auto_ptr`. For example, in case of
> > Boost.Python we also need to specialize templates so users can continue
> > using `std::auto_ptr` in their own code, unless they explicitly (using
> > macros) or implicitly (using modern compilers) disable such
> > backward-compatible support. I suppose there are other Boost libraries
> > in a similar situation.
> >
> >
> Here's a sample of the warnings -- looks to me like the python case all the
> warnings come from detail - so for modes past c++11 I'd think unique_ptr
> could be used.  A macro for python could allow users to override the
> removal and use auto_ptr in their code if they choose.  And this problem is
> isolated to python and locale.
>
> ./boost/locale/localization_backend.hpp:116:59: warning: ‘template<class>
> class std::auto_ptr’ is deprecated [-Wdeprecated-declarations]
> ./boost/locale/util.hpp:180:28: warning: ‘template<class> class
> std::auto_ptr’ is deprecated [-Wdeprecated-declarations]
> ./boost/python/detail/is_auto_ptr.hpp:17:40: warning: ‘template<class>
> class std::auto_ptr’ is deprecated [-Wdeprecated-declarations]
> ./boost/python/detail/is_auto_ptr.hpp:17:40: warning: ‘template<class>
> class std::auto_ptr’ is deprecated [-Wdeprecated-declarations]
>
>
Those boost headers could use:

#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
...
#pragma GCC diagnostic pop

around the uses of auto_ptr. That will prevent warnings coming from those
uses.

If users use auto_ptr in their own code then surely those users should be
responsible for disabling the warnings coming from their own code? If you
use the pragmas above then they won't get warnings from the Boost headers,
even if they pass their auto_ptr objects to the Boost functions. They'd
only get warnings for their own uses of auto_ptr in their own code, which
as I said, is their concern not Boost's.