On 11/10/2015 6:09 PM, Vladimir Batov wrote:
On 11/11/2015 03:03 AM, Zach Laine wrote:
On Tue, Nov 10, 2015 at 8:47 AM, Artyom Beilis
wrote: I don't see ANY reason whatsoever to break existing code unless the use of some code opens some critical security bugs like gets() for example. ... I think this proposal is totally disconnected from real world. ... ... I agree with the author of that paper that the use of auto_ptr *is* broken in the general case, and so it should be deprecated and removed.
Deprecating and removing are not quite the same with very different outcomes to the end-user. No matter how much one likes C++11 and how much auto_prt is "broken" it appears outright irresponsible removing such an important and well-entrenched component with huge impact onto the end-user code base. The concern expressed by Artyom is well-justified. There cannot be ifs and buts about it.
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. 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.