I think it’s more a question of philosophy than technic 🙂 The underlying question is what is the difference between Move and Copy. I won’t jump into technical / standardista language, let’s do it simply: Copy: create another identical object (or at least, one which SHOULD compare equal) Move: take an object and put it … Read more
UPDATE: This answer was written in 2010 and as anticipated std::auto_ptr has been deprecated. The advice is entirely valid. In C++0x std::auto_ptr will be deprecated in favor of std::unique_ptr. The choice of smart pointer will depend on your use case and your requirements, with std::unique_ptr with move semantics for single ownership that can be used … Read more
The direct replacement for auto_ptr (or the closest thing to one anyway) is unique_ptr. As far as the “problem” goes, it’s pretty simple: auto_ptr transfers ownership when it’s assigned. unique_ptr also transfers ownership, but thanks to codification of move semantics and the magic of rvalue references, it can do so considerably more naturally. It also … Read more
You cannot do a global find/replace because you can copy an auto_ptr (with known consequences), but a unique_ptr can only be moved. Anything that looks like std::auto_ptr<int> p(new int); std::auto_ptr<int> p2 = p; will have to become at least like this std::unique_ptr<int> p(new int); std::unique_ptr<int> p2 = std::move(p); As for other differences, unique_ptr can handle … Read more
The C++ Standard says that an STL element must be “copy-constructible” and “assignable.” In other words, an element must be able to be assigned or copied and the two elements are logically independent. std::auto_ptr does not fulfill this requirement. Take for example this code: class X { }; std::vector<std::auto_ptr<X> > vecX; vecX.push_back(new X); std::auto_ptr<X> pX … Read more