Repository navigation
std::auto_ptr is deprecated warning at boost/python/detail/is_auto_ptr.hpp:17 #176
Description
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)
^~~~~~~~~~~~~~~~~~~~~~~
Activity
stefanseefeld commentedon Nov 13, 2017
That's fully expected and not a bug. Boost.Python needs to support
std::auto_ptrfor backward-compatibility. We may need to mask theis_auto_ptr<>trait eventually, on platforms that don't havestd::auto_ptrany 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 commentedon Nov 13, 2017
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 commentedon Nov 13, 2017
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 commentedon Nov 13, 2017
Fair enough. I'll see what I can do.
jeking3 commentedon Nov 13, 2017
Thanks, if you want me to submit a PR for this issue let me know.
stefanseefeld commentedon Nov 13, 2017
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 commentedon Nov 13, 2017
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 commentedon Nov 13, 2017
Also seeing this. Treat it separately?
stefanseefeld commentedon Nov 13, 2017
Feel free to include it into the same PR, but make it a separate commit. Thanks.
jeking3 commentedon Nov 13, 2017
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.