On 11/11/2015 02:46, Artyom Beilis wrote:
The point is that semantics of auto_ptr makes it clear who owns what, it works well for more than a decade and of course well known to users.
Anecdotal evidence suggests that many users of auto_ptr did not find its behaviour sufficiently well known to avoid using it in buggy ways. The problem is that most of the ways to use it "wrong" arise out of default compiler behaviour that can kick in with seemingly innocent code when you simply forget to do certain things (like disable or reimplement the copy constructor). Whereas unique_ptr will give you compiler errors until you fix the code, making it inherently safer, if at times a little more annoying. Having said that, I do currently use auto_ptr (in a safe way) in some code of my own (since it came from C++03 roots, and is now dual compiled), and I'm a little sad about the decision to remove it entirely in the near future. Deprecation makes sense though, and in my case at least it's relatively simple to replace with unique_ptr. I suspect though that if it's not removed at some point, then people will continue using it incorrectly; this was probably a factor in the committee's decision to remove it rather than merely leaving it deprecated, and similarly for MS following suit.
Applying the deprecated-to-removed transition in just a few years seems hasty. That impression comes from mentioned (http://blogs.msdn.com/b/vcblog/archive/2015/04/29/c-11-14-17-features-in-vs-...) indicating that the second "major version" after VS2015 (2019?) auto_ptr won't be available. If I understood it correctly, I found it concerning... but I feel common sense will prevail. :)
So, seven years is hasty? :)