std::auto_ptr is deprecated warning at boost/python/detail/is_auto_ptr.hpp:17

[jeking3]

Brand new clone of master on Ubuntu Trusty with gcc-7.2 installed, this warning appeared in the build:

Command: ./b2 address-model=64 link=shared threading=multi toolset=gcc-7 variant=release -q -j5
Output:

In file included from ./boost/python/detail/is_xxx.hpp:8:0,
                 from ./boost/python/detail/is_auto_ptr.hpp:9,
                 from ./boost/python/detail/copy_ctor_mutates_rhs.hpp:8,
                 from ./boost/python/detail/value_arg.hpp:7,
                 from ./boost/python/object/forward.hpp:10,
                 from ./boost/python/object/pointer_holder.hpp:16,
                 from ./boost/python/to_python_indirect.hpp:10,
                 from ./boost/python/converter/arg_to_python.hpp:10,
                 from ./boost/python/call.hpp:15,
                 from ./boost/python/object_core.hpp:14,
                 from ./boost/python/object/function.hpp:12,
                 from ./boost/python/object/function_doc_signature.hpp:8,
                 from libs/python/src/object/function_doc_signature.cpp:10:
./boost/python/detail/is_auto_ptr.hpp:17:40: warning: ‘template<class> class std::auto_ptr’ is deprecated [-Wdeprecated-declarations]
 BOOST_PYTHON_IS_XXX_DEF(auto_ptr, std::auto_ptr, 1)
                                        ^
./boost/detail/is_xxx.hpp:20:4: note: in definition of macro ‘BOOST_DETAIL_IS_XXX_DEF’
    qualified_name< BOOST_PP_ENUM_PARAMS_Z(1, nargs, T) >        \
    ^~~~~~~~~~~~~~
./boost/python/detail/is_auto_ptr.hpp:17:1: note: in expansion of macro ‘BOOST_PYTHON_IS_XXX_DEF’
 BOOST_PYTHON_IS_XXX_DEF(auto_ptr, std::auto_ptr, 1)
 ^~~~~~~~~~~~~~~~~~~~~~~

[stefanseefeld]

That's fully expected and not a bug. Boost.Python needs to support std::auto_ptr for backward-compatibility. We may need to mask the is_auto_ptr<> trait eventually, on platforms that don't have std::auto_ptr any longer, but until we get to that point (and have the machinery to conditionally enable / disable support for std::auto_ptr, I'm inclined to keep things the way they are.

[jeking3]

I would respectfully request that you reconsider squelching this compiler warning where it is being emitted through the use of toolset specific build options in your project. Builds should not have warnings.

[jeking3]

Actually, it would be more of a pragma thing than a build option thing, but you get the idea... if the library requires it, but it is deprecated, the library could squelch the warning through compiler pragmas for controlling diagnostics to make a cleaner build.

[stefanseefeld]

Fair enough. I'll see what I can do.

[jeking3]

Thanks, if you want me to submit a PR for this issue let me know.

[stefanseefeld]

Sure, that would be great. I'm not quite sure yet what the desired behaviour should be, though. Are you suggesting to merely disable the warning, or change actual code / behaviour ?
We can discuss this with the PR in any case. Thanks !

[jeking3]

I would say that given Boost.Python has a requirement to detect/support std::auto_ptr, and given newer compilers issue a warning on use of std:auto_ptr, we should disable those warnings around those specific cases if we can in order to achieve a warning-free build. I often build my code with warnings as errors and -Wextra or /W4 enabled because often times these point out subtle bugs, and once a project can build warning free, keeping it warning-free is a good practice. Boost in general has too many build warnings for my taste and I would like to help push us all towards having warning-free builds and turning on "warning-as-error" semantics for our own boost builds.

Let me see what I can do and submit a PR for this.

[jeking3]

Also seeing this. Treat it separately?

In file included from libs/python/src/str.cpp:5:0:
./boost/python/extract.hpp: In member function ‘long int boost::python::detail::str_base::count(boost::python::api::object_operators<boost::python::api::object>::object_cref) const’:
./boost/python/extract.hpp:185:11: warning: ‘*((void*)&<anonymous> +24)’ may be used uninitialized in this function [-Wmaybe-uninitialized]
           );
           ^
./boost/python/extract.hpp: In member function ‘long int boost::python::detail::str_base::count(boost::python::api::object_operators<boost::python::api::object>::object_cref, boost::python::api::object_operators<boost::python::api::object>::object_cref) const’:
./boost/python/extract.hpp:185:11: warning: ‘*((void*)&<anonymous> +24)’ may be used uninitialized in this function [-Wmaybe-uninitialized]
           );
           ^
./boost/python/extract.hpp: In member function ‘long int boost::python::detail::str_base::count(boost::python::api::object_operators<boost::python::api::object>::object_cref, boost::python::api::object_operators<boost::python::api::object>::object_cref, boost::python::api::object_operators<boost::python::api::object>::object_cref) const’:
./boost/python/extract.hpp:185:11: warning: ‘*((void*)&<anonymous> +24)’ may be used uninitialized in this function [-Wmaybe-uninitialized]
           );
           ^

[stefanseefeld]

Feel free to include it into the same PR, but make it a separate commit. Thanks.

[jeking3]

It looks like if one builds with BOOST_NO_AUTO_PTR defined this goes away. That seems like an acceptable solution to me. As such, I am going to close this out.