Re: [release] Boost 1.74.0 Release Candidate 1

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [release] Boost 1.74.0 Release Candidate 1

Boost - Dev mailing list
My compile report the RC:

1 platforms, 4 compilers, 5 c++ versions as applicable
- All successfully compile, so pretty solid
- gcc10.1 2a mode had 154 warnings
  - All in agreement the locale library has deprecated auto_ptr with
copious warnings (most of the ~95 warnings on g++ compiles)
  - python auto_ptr is another source
  - this is a bit better than 1.73

Mint5 - 5.0.0-32-generic #34~18.04.2-Ubuntu SMP Thu Oct 10 10:36:02 UTC
2019 x86_64 x86_64 x86_64 GNU/Linux
g++10.1 (2a, 17, 14, 11, 98)
g++9.2 (2a, 17, 14, 11, 98)
g++7.5 (17, 14, 11, 98)
clang6.0.0 (17, 14, 11, 98


On Sat, Aug 8, 2020 at 9:36 PM Marshall Clow via Boost <
[hidden email]> wrote:

> On Aug 7, 2020, at 8:13 AM, Marshall Clow <[hidden email]> wrote:
> >
> > The first release candidates for the 1.74.0 release are now available at:
> >
> > <https://dl.bintray.com/boostorg/release/1.74.0/source/ <
> https://dl.bintray.com/boostorg/release/1.74.0/source/>>
> >
> > The SHA256 checksums are as follows:
> >
> > 9ea3fc8573413f4d4b2c4d448110b6cb0467df834304112e143c7edb09ae71e9
> boost_1_74_0_rc1.7z
> > 8b6c429a41f7cac1880594adf8d1d6f0cc1cf19f8980c6b86ac38ef8b3d8a4e0
> boost_1_74_0_rc1.tar.bz2
> > a0a96a9bb3863863e034cafc825b2ddba4249c7d278b76df1277295e7c7afbf2
> boost_1_74_0_rc1.tar.gz
> > d4f31cce9d5fbd55691dc2f5fb73380e95aa66426c891ceb3ebdfc6616022842
> boost_1_74_0_rc1.zip
> >
> > As always, the release managers would appreciate it if you download the
> > candidate of your choice and give building it a try. Please report both
> > success and failure, and anything else that is noteworthy.
>
> I was able to successfully build the libraries on Mac OS 10.15 using:
> Apple clang version 11.0.3 (clang-1103.0.32.62)  using C++03/11/14/17/2a
>
> And with a recent ToT clang using C++03/11/14/17/2a
>
> — Marshall
>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Boost - Dev mailing list
Hi all,

On 2020-08-11 9:41 a.m., Jeff Garland via Boost wrote:
> My compile report the RC:
>
> 1 platforms, 4 compilers, 5 c++ versions as applicable
> - All successfully compile, so pretty solid
> - gcc10.1 2a mode had 154 warnings
>    - All in agreement the locale library has deprecated auto_ptr with
> copious warnings (most of the ~95 warnings on g++ compiles)
>    - python auto_ptr is another source
>    - this is a bit better than 1.73

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.

Thanks,

Stefan
--

       ...ich hab' noch einen Koffer in Berlin...


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Boost - Dev mailing list
On Tue, Aug 11, 2020 at 6:52 AM Stefan Seefeld via Boost <
[hidden email]> 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]

Jeff

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Boost - Dev mailing list

On 2020-08-11 10:07 a.m., Jeff Garland via Boost wrote:

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

Note that the usage in Boost.Python is already wrapped in

`# if !defined(BOOST_NO_AUTO_PTR)`

so in principle that code shouldn't be visible in C++14 and beyond.
Hence my question.

I'll investigate.

Thanks,

Stefan
--

       ...ich hab' noch einen Koffer in Berlin...


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Boost - Dev mailing list
On Tue, Aug 11, 2020 at 7:17 AM Stefan Seefeld via Boost <
[hidden email]> wrote:

>
> Note that the usage in Boost.Python is already wrapped in
>
> `# if !defined(BOOST_NO_AUTO_PTR)`
>
>
Interesting.


> so in principle that code shouldn't be visible in C++14 and beyond.
> Hence my question.
>
> I'll investigate.
>
>
You're right -- it looks like the logic is there.   Maybe the
is_auto_ptr.hpp just doesn't have it in the include path (it isn't there
directly).

 config/libstdcpp3.hpp

// std::auto_ptr isn't provided with _GLIBCXX_DEPRECATED=0 (GCC 4.5 and
earlier)
// or _GLIBCXX_USE_DEPRECATED=0 (GCC 4.6 and later).
#if defined(BOOST_LIBSTDCXX11)
#  if BOOST_LIBSTDCXX_VERSION < 40600
#     if !_GLIBCXX_DEPRECATED
#        define BOOST_NO_AUTO_PTR
#     endif
#  elif !_GLIBCXX_USE_DEPRECATED
#     define BOOST_NO_AUTO_PTR
#  endif
#endif

Jeff

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Boost - Dev mailing list
On Tue, Aug 11, 2020 at 7:46 AM Jeff Garland <[hidden email]> wrote:

>
>
> On Tue, Aug 11, 2020 at 7:17 AM Stefan Seefeld via Boost <
> [hidden email]> wrote:
>
>>
>> Note that the usage in Boost.Python is already wrapped in
>>
>> `# if !defined(BOOST_NO_AUTO_PTR)`
>>
>>
> Interesting.
>
>
>> so in principle that code shouldn't be visible in C++14 and beyond.
>> Hence my question.
>>
>> I'll investigate.
>>
>>
> You're right -- it looks like the logic is there.   Maybe the
> is_auto_ptr.hpp just doesn't have it in the include path (it isn't there
> directly).
>
>  config/libstdcpp3.hpp
>
>
btw I did this experiment and it didn't work so something else non obvious
is happening.

Jeff

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Tue, 11 Aug 2020 at 15:08, Jeff Garland via Boost <[hidden email]>
wrote:

> On Tue, Aug 11, 2020 at 6:52 AM Stefan Seefeld via Boost <
> [hidden email]> 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.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost