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

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 20 May 2017 at 17:29, Daniela Engert via Boost 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.

On 22 May 2017 at 06:56, Daniela Engert via Boost wrote:

Am 21.05.2017 um 19:41 schrieb Daniel James via Boost:

...

On 20 May 2017 at 17:29, Daniela Engert via Boost 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.

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 wrote:

Andrey Semashev wrote:

...

Here is a reply of Boost.Locale developer to a similar question from me:

https://lists.boost.org/Archives/boost/2015/11/226475.php

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

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

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

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

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