std::auto_ptr in public interfaces
Hi everybody, you are probably aware of the fact that the upcoming C++17 standard is going to remove std:auto_ptr (and other deprecated features), and that MSVC 14.0 and 14.1 no longer supply these deprecated, to-be-removed features when compiling in a 'later than C++14' mode (i.e. /std::c++latest or /std:c++17). Today I've learned that latest versions of libc++ also no longer supply std::auto_ptr when compiled in C++17 mode. Some time ago I've talked about an in-house version of Boost which no longer requires these deprecated features and builds and passes tests in C++17 mode. As of yesterday I've completed my pull-requests against all those libraries using any of these features (¹), to deal with this situation where required - except for two libraries: locale and ptr_container. These two remaining libraries use std::auto_ptr in their public interfaces and replacing std::auto_ptr with std::unique_ptr is not as easy as a replacement of std::auto_ptr used in the bowels of a library or in test code. It would impose respective changes to user code as well. In our company we just got rid of all traces of std::auto_ptr and happily keep on using locale and ptr_container just as before. So guys, what's your opinion of how to deal with this situation? Ciao Dani ¹ algorithm, asio, assign, bimap, container, gil, graph, icl, interprocess, intrusive, lockfree, msm, phoenix, polygon, random, range, regex, statechart, test, typeof, wave, xpressive -- PGP/GPG: 2CCB 3ECB 0954 5CD3 B0DB 6AA0 BA03 56A1 2C4638C5
On 05/20/17 17:30, Daniela Engert via Boost wrote:
Hi everybody,
you are probably aware of the fact that the upcoming C++17 standard is going to remove std:auto_ptr (and other deprecated features), and that MSVC 14.0 and 14.1 no longer supply these deprecated, to-be-removed features when compiling in a 'later than C++14' mode (i.e. /std::c++latest or /std:c++17). Today I've learned that latest versions of libc++ also no longer supply std::auto_ptr when compiled in C++17 mode. Some time ago I've talked about an in-house version of Boost which no longer requires these deprecated features and builds and passes tests in C++17 mode. As of yesterday I've completed my pull-requests against all those libraries using any of these features (¹), to deal with this situation where required - except for two libraries: locale and ptr_container. These two remaining libraries use std::auto_ptr in their public interfaces and replacing std::auto_ptr with std::unique_ptr is not as easy as a replacement of std::auto_ptr used in the bowels of a library or in test code. It would impose respective changes to user code as well. In our company we just got rid of all traces of std::auto_ptr and happily keep on using locale and ptr_container just as before. So guys, what's your opinion of how to deal with this situation?
Here is a reply of Boost.Locale developer to a similar question from me: https://lists.boost.org/Archives/boost/2015/11/226475.php Personally, I would prefer libraries to switch to boost::unique_ptr and leave std::auto_ptr interfaces available (but deprecated) for backward compatibility. But I'm not a maintainer of either of the libraries in question.
Am 20.05.2017 um 17:28 schrieb Andrey Semashev via Boost:
... Personally, I would prefer libraries to switch to boost::unique_ptr and leave std::auto_ptr interfaces available (but deprecated) for backward compatibility.
But, if you break the interface and people's code by replacing std::auto_ptr by boost::unique_ptr (is there such a thing in the first place, I couldn't find one in Boost.Smart_ptr?), why not just going straight to std::unique_ptr? Users affected by this problem definitely have std::unique_ptr available and certainly don't need a non-standard compatibility solution. What does a boost:unique_ptr solution buy you? Ciao Dani -- PGP/GPG: 2CCB 3ECB 0954 5CD3 B0DB 6AA0 BA03 56A1 2C4638C5
On 05/20/17 18:45, Daniela Engert via Boost wrote:
Am 20.05.2017 um 17:28 schrieb Andrey Semashev via Boost:
... Personally, I would prefer libraries to switch to boost::unique_ptr and leave std::auto_ptr interfaces available (but deprecated) for backward compatibility.
But, if you break the interface and people's code by replacing std::auto_ptr by boost::unique_ptr
I'm not suggesting to break code, at least not until absolutely needed. All APIs that contain std::auto_ptr would likely have to be duplicated with boost::unique_ptr equivalents.
(is there such a thing in the first place, I couldn't find one in Boost.Smart_ptr?),
It's part of Boost.Move. https://github.com/boostorg/move/blob/develop/include/boost/move/unique_ptr.... Right, I forgot it's boost::movelib::unique_ptr, not boost::unique_ptr. Ideally, it should be moved to Boost.SmartPtr as that's the more appropriate library for such a component, IMO.
why not just going straight to std::unique_ptr?
Because you would lose compatibility with C++03, which I presume the authors of the libraries want to keep. Also, the API and ABI would be C++ version agnostic this way.
Am 20.05.2017 um 18:16 schrieb Andrey Semashev via Boost:
On 05/20/17 18:45, Daniela Engert via Boost wrote:
Am 20.05.2017 um 17:28 schrieb Andrey Semashev via Boost:
... Personally, I would prefer libraries to switch to boost::unique_ptr and leave std::auto_ptr interfaces available (but deprecated) for backward compatibility. why not just going straight to std::unique_ptr?
Because you would lose compatibility with C++03, which I presume the authors of the libraries want to keep.
But you are proposing to keep the auto_ptr-based interface for that purpose, too. I don't see the benefit of two solutions for the same problems sitting side-by-side. Users who want to stick with std::auto_ptr just keep on using the current interface, and users who need to get rid of std::auto_ptr in all of their code have to find a solution for their entire code base how to deal with that. Insisting on yet another non-standard option to interface with Boost is not necessarily what these people have in mind, imho. Ciao Dani -- PGP/GPG: 2CCB 3ECB 0954 5CD3 B0DB 6AA0 BA03 56A1 2C4638C5
On 05/20/17 19:29, Daniela Engert via Boost wrote:
Am 20.05.2017 um 18:16 schrieb Andrey Semashev via Boost:
On 05/20/17 18:45, Daniela Engert via Boost wrote:
Am 20.05.2017 um 17:28 schrieb Andrey Semashev via Boost:
... Personally, I would prefer libraries to switch to boost::unique_ptr and leave std::auto_ptr interfaces available (but deprecated) for backward compatibility. why not just going straight to std::unique_ptr?
Because you would lose compatibility with C++03, which I presume the authors of the libraries want to keep.
But you are proposing to keep the auto_ptr-based interface for that purpose, too.
I'm proposing to keep it for backward compatibility, deprecated, with the intention to remove it at some point. The up-to-date interface would use boost::unique_ptr, for C++03 and C++11 and so on.
I don't see the benefit of two solutions for the same problems sitting side-by-side. Users who want to stick with std::auto_ptr just keep on using the current interface, and users who need to get rid of std::auto_ptr in all of their code have to find a solution for their entire code base how to deal with that. Insisting on yet another non-standard option to interface with Boost is not necessarily what these people have in mind, imho.
I don't see another option if one (a Boost library developer or a Boost user) wants to keep his code stable across all C++ versions. If the standard library is not portable across different C++ versions (it is not) then you either lock yourself to particular C++ versions or simply do not use the standard library.
On 20 May 2017 at 17:29, Daniela Engert via Boost <boost@lists.boost.org> wrote:
But you are proposing to keep the auto_ptr-based interface for that purpose, too. I don't see the benefit of two solutions for the same problems sitting side-by-side. Users who want to stick with std::auto_ptr just keep on using the current interface, and users who need to get rid of std::auto_ptr in all of their code have to find a solution for their entire code base how to deal with that. Insisting on yet another non-standard option to interface with Boost is not necessarily what these people have in mind, imho.
I don't think it's realistic to expect everyone to update their entire code base at once. Especially if they're using code from multiple sources. It should be as easy as possible to start using new versions, any friction can result in people getting stuck on old versions which makes life harder for everyone. If two dependencies both use the same boost library, then it's unlikely they'll both update simultaneously, so making it an either/or choice can cause real problems.
Am 21.05.2017 um 19:41 schrieb Daniel James via Boost:
On 20 May 2017 at 17:29, Daniela Engert via Boost <boost@lists.boost.org> wrote:
I don't think it's realistic to expect everyone to update their entire code base at once. Especially if they're using code from multiple sources. It should be as easy as possible to start using new versions, any friction can result in people getting stuck on old versions which makes life harder for everyone. If two dependencies both use the same boost library, then it's unlikely they'll both update simultaneously, so making it an either/or choice can cause real problems.
I totally agree with you Daniel, but I'm not sure if we are on the same page here. Andrey's proposal is to have the existing interface based on std::auto-ptr side-by-side with a new one based on a future boost::unique_ptr, deprecating the std::auto_ptr interface. My proposal differs only in going to std::unique_ptr rather than boost::unique_ptr. The rationale is that users affected by the removal of std::auto_ptr from their standard libraries when in C++17 mode have std::unique_ptr available anyway. There are multiple options to handle this situation, but ignoring it is no option at all: unless you do at least *anything* you can't compile code with std::auto_ptr in it, and you can't link to code using it in it's interface. This is what I meant then talking about the removal of std::auto_ptr affecting the whole codebase. Ciao Dani -- PGP/GPG: 2CCB 3ECB 0954 5CD3 B0DB 6AA0 BA03 56A1 2C4638C5
On 22 May 2017 at 06:56, Daniela Engert via Boost <boost@lists.boost.org> wrote:
Am 21.05.2017 um 19:41 schrieb Daniel James via Boost:
On 20 May 2017 at 17:29, Daniela Engert via Boost <boost@lists.boost.org> wrote:
I don't think it's realistic to expect everyone to update their entire code base at once. Especially if they're using code from multiple sources. It should be as easy as possible to start using new versions, any friction can result in people getting stuck on old versions which makes life harder for everyone. If two dependencies both use the same boost library, then it's unlikely they'll both update simultaneously, so making it an either/or choice can cause real problems.
I totally agree with you Daniel, but I'm not sure if we are on the same page here. Andrey's proposal is to have the existing interface based on std::auto-ptr side-by-side with a new one based on a future boost::unique_ptr, deprecating the std::auto_ptr interface. My proposal differs only in going to std::unique_ptr rather than boost::unique_ptr.
Sorry, I misunderstood what you meant by two solutions sitting side-by-side.
Andrey Semashev wrote:
Here is a reply of Boost.Locale developer to a similar question from me:
He may reconsider now that std::auto_ptr is not merely a warning, but an error.
For what it's worth my view is that c++17 is a breaking change from c++14. The boost interfaces have to move to unique_ptr at this point since anyone upgrading to 17 has to deal with the auto_ptr to unique_ptr move in all code anyway. If the maintainers have the bandwidth, I'd like my c++14 code to stop whining about auto_ptr when I link to boost. Since auto_ptr is deprecated in 14 I'd prefer to see the auto_ptr interface vanish when building for 14 unless I specifically request it by defining the preprocess or symbol BOOST_ALLOW_AUTO_PTR or some such. After all I deliberately compiled with c++14. I already knew that auto_ptr was deprecated. Having said this, in my firm I mandate that we move to the newest released standard as soon as clang and gcc support it properly, so I guess I'll only have to see hose warning for a few months more. R On Sat, 20 May 2017 at 18:51, Peter Dimov via Boost <boost@lists.boost.org> wrote:
Andrey Semashev wrote:
Here is a reply of Boost.Locale developer to a similar question from me:
He may reconsider now that std::auto_ptr is not merely a warning, but an error.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 5/20/17 10:18 AM, Richard Hodges via Boost wrote:
If the maintainers have the bandwidth, I'd like my c++14 code to stop whining about auto_ptr when I link to boost. Since auto_ptr is deprecated in 14 I'd prefer to see the auto_ptr interface vanish when building for 14 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. As an aside, config.hpp, developed / maintained by John Maddoc is a masterpiece which is the cornerstone of boost. Without this we would have not been able to get library development working across the wide variety of C++ compilers we have addressed. Without this, there is no way the serialization library (for example) could hope to maintain backward compatibility for code AND data. Without this, neither Boost nor C++ would be where they are today. And it's not just a trick - it's a huge effort in it's own right. A large majority of boost users, and even some developers fail to understand and appreciate this this. Robert Ramey
[Robert Ramey]
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.
MSVC's documented (since I say so) macro to control/report auto_ptr's availability is _HAS_AUTO_PTR_ETC which is defined to be either 0 or 1 (and you just have to include any STL header, e.g. good old <ciso646>). Additionally, in VC 2017's second toolset update (not the first one that's being released soon), I am planning to aggressively warn about C++17's deprecated features in C++17 mode (/std:c++17 or /std:c++latest). All of the library stuff in Annex D will emit warnings, except for the <meow.h> C headers (it's silly that they're deprecated). (I can't warn about <codecvt> at the moment due to a compiler bug, but hopefully that'll be fixed so I can add those warnings.) This is going to be pretty noisy, but it'll ultimately make migrating code to C++20 and beyond easier. I plan to have a system of fine-grained escape hatch macros, and a big "silence all C++17 deprecation warnings" macro, but libraries like Boost will need to avoid the deprecated components (or locally suppress C4996) since they don't really control the user's preferences. Auditing Boost right now for unnecessary use of the Annex D stuff would be a good idea. Stuff like std::iterator, the old allocator members, and std::result_of are probably commonly used. STL
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'). 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. 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?
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
On 21/05/2017 18:06, Daniela Engert wrote:
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'). 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.
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.
There's already some examples of this in existing Boost code; one of the most obvious is boost/get_pointer.hpp, which provides std::auto_ptr overloads unless BOOST_NO_AUTO_PTR is defined, and std::unique_ptr and std::shared_ptr overloads unless BOOST_NO_CXX11_SMART_PTR is defined. If anything else that currently uses std::auto_ptr in its public interface does likewise, then everybody should be happy: - those using C++98/03 compilers can continue using std::auto_ptr. - those using C++11/14 compilers get both and their old code will compile while allowing them to convert to std::unique_ptr at their leisure. (The compiler should be giving them deprecation warnings, so they know to do this.) - those using C++17 compilers don't get the std::auto_ptr version, which would no longer compile. It's a little trickier for implementation details; there it's probably best to always use std::unique_ptr, unless BOOST_NO_CXX11_SMART_PTR is defined. Fortunately nobody should be returning an auto_ptr by reference, so that shouldn't cause any problems for the interface.
Am 23.05.2017 um 01:56 schrieb Gavin Lambert via Boost:
If anything else that currently uses std::auto_ptr in its public interface does likewise, then everybody should be happy:
- those using C++98/03 compilers can continue using std::auto_ptr.
- those using C++11/14 compilers get both and their old code will compile while allowing them to convert to std::unique_ptr at their leisure. (The compiler should be giving them deprecation warnings, so they know to do this.)
- those using C++17 compilers don't get the std::auto_ptr version, which would no longer compile.
There it is, my take on Boost.Ptr_container: https://github.com/boostorg/ptr_container/pull/8 This passes the testsuite just like vanilla develop when compiled with * msvc 9.0 which has no std::unique_ptr * msvc 14.x in a mode without std::auto_ptr * msvc 12.0 which has both std::auto_ptr and std::unique_ptr The std::auto_ptr-based library interface can be deliberately disabled, and similarly the std::auto_ptr-based tests. I'm all ears for suggestions, pointing out errors, whatever ... Ciao Dani -- PGP/GPG: 2CCB 3ECB 0954 5CD3 B0DB 6AA0 BA03 56A1 2C4638C5
Den 23-05-2017 kl. 16:36 skrev Daniela Engert via Boost:
Am 23.05.2017 um 01:56 schrieb Gavin Lambert via Boost:
If anything else that currently uses std::auto_ptr in its public interface does likewise, then everybody should be happy:
- those using C++98/03 compilers can continue using std::auto_ptr.
- those using C++11/14 compilers get both and their old code will compile while allowing them to convert to std::unique_ptr at their leisure. (The compiler should be giving them deprecation warnings, so they know to do this.)
- those using C++17 compilers don't get the std::auto_ptr version, which would no longer compile.
There it is, my take on Boost.Ptr_container: https://github.com/boostorg/ptr_container/pull/8
This passes the testsuite just like vanilla develop when compiled with * msvc 9.0 which has no std::unique_ptr * msvc 14.x in a mode without std::auto_ptr * msvc 12.0 which has both std::auto_ptr and std::unique_ptr
Nice.
The std::auto_ptr-based library interface can be deliberately disabled, and similarly the std::auto_ptr-based tests.
I'm all ears for suggestions, pointing out errors, whatever ...
A. so you pass unique_ptr<T> by value ... is that the preferred way compared to unique_ptr<T>&& ? B. I wouldn't provide unique_ptr versions for clone()/constructor, but implement container( container&& ) = default; container& operator=( container&& ) = default; C. I would change auto_type to unique_ptr<T> for C++11 (or whatever boost macro that says it is there) kind regards Thorsten
On 5/20/2017 1:46 PM, Robert Ramey via Boost wrote:
On 5/20/17 10:18 AM, Richard Hodges via Boost wrote:
If the maintainers have the bandwidth, I'd like my c++14 code to stop whining about auto_ptr when I link to boost. Since auto_ptr is deprecated in 14 I'd prefer to see the auto_ptr interface vanish when building for 14 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.
As an aside, config.hpp, developed / maintained by John Maddoc
John Maddock
is a masterpiece which is the cornerstone of boost. Without this we would have not been able to get library development working across the wide variety of C++ compilers we have addressed. Without this, there is no way the serialization library (for example) could hope to maintain backward compatibility for code AND data. Without this, neither Boost nor C++ would be where they are today. And it's not just a trick - it's a huge effort in it's own right. A large majority of boost users, and even some developers fail to understand and appreciate this this.
Only A fool does not appreciate what Boost Config does.
Robert Ramey
On 5/20/2017 10:30 AM, Daniela Engert via Boost wrote:
Hi everybody,
you are probably aware of the fact that the upcoming C++17 standard is going to remove std:auto_ptr (and other deprecated features), and that MSVC 14.0 and 14.1 no longer supply these deprecated, to-be-removed features when compiling in a 'later than C++14' mode (i.e. /std::c++latest or /std:c++17). Today I've learned that latest versions of libc++ also no longer supply std::auto_ptr when compiled in C++17 mode. Some time ago I've talked about an in-house version of Boost which no longer requires these deprecated features and builds and passes tests in C++17 mode. As of yesterday I've completed my pull-requests against all those libraries using any of these features (¹), to deal with this situation where required - except for two libraries: locale and ptr_container. These two remaining libraries use std::auto_ptr in their public interfaces and replacing std::auto_ptr with std::unique_ptr is not as easy as a replacement of std::auto_ptr used in the bowels of a library or in test code. It would impose respective changes to user code as well. In our company we just got rid of all traces of std::auto_ptr and happily keep on using locale and ptr_container just as before. So guys, what's your opinion of how to deal with this situation?
If config has a BOOST_NO_AUTO_PTR the locale and ptr_container libraries need to check that and provide an alternative implementation instead.
Ciao Dani
¹ algorithm, asio, assign, bimap, container, gil, graph, icl, interprocess, intrusive, lockfree, msm, phoenix, polygon, random, range, regex, statechart, test, typeof, wave, xpressive
participants (10)
-
Andrey Semashev -
Daniel James -
Daniela Engert -
Edward Diener -
Gavin Lambert -
Peter Dimov -
Richard Hodges -
Robert Ramey -
Stephan T. Lavavej -
Thorsten Ottosen