On 11 November 2015 at 01:17, Edward Diener wrote:
I believe one is allowed to say that Y does everything that X does and is better and therefore X will be removed at some time in the future. If one cannot say that then computer programming will never advance to the use of better programming idioms. I don't believe that one must carry the baggage of X forever because some programmers want to use X in perpetuity.
Yes, well said.
This is a general reflection and is not a specific argument for std::unique_ptr versus std::auto_ptr. However technically std::unique_ptr appears to me to be a superior programming idiom than std::auto_ptr and while I am not going to argue over a date in which std::auto_ptr should no longer be part of the C++ standard library, it seems inevitable to me that at some time in the future it would be removed from the C++ standard library.
It has already been removed from the current C++ working paper (what will be C++17). That doesn't mean implementors have to stop providing it, it only means it is no longer defined by the standard. Supporting older versions of the standard and users who mix old and new code is the implementors job, it doesn't need to be supported by the C++17 standard. The C++17 standard defines C++17, not C++-a-bit-of-this-and-a-bit-of-that. If you have important reasons to keep using std::auto_ptr in modern code then convince your standard library vendor to keep providing it. (Although in this case I think using Boost's own unique_ptr makes far more sense than throwing a hissy fit because a widely-misused class has been removed. The C++ committee regularly gets criticised for too much backwards compatibility, so while one angry person on the internet is annoyed the first time a deprecated feature is actually removed there are probably far more people saying "at last!!!").