auto-ptr

auto_ptr_ref documentation here says this This is an instrumental class to allow certain conversions that allow auto_ptr objects to be passed to and returned from functions. Can somebody explain how auto_ptr_ref helps in achieving this. I just want to understand the auto_ptr class and its internals It is rather confusing. Basically, auto_ptr_ref exists because the auto_ptr copy constructor isn't really a copy constructor in the standard sense of the word. Copy constructors typically have a signature that looks like this: X(const X &b); The auto_ptr copy constructor has a signature that looks

When trying to use an auto_ptr with a type that was declared with forward-declaration, like this: class A; ... std::auto_ptr<A> a; the destructor of A is not called (apparently, because auto_ptr internally delete s the underlying pointer and the destructor for an incomplete type cannot be called). However, the same code works fine and the destructor is called when using std::shared_ptr instead of std::auto_ptr . How can that be explained? A shared_ptr can be declared with an incomplete type, yes. The type does not need to be complete until you initialize or reset it. When you initialize or

Back on my crazy AutoArray thingy ... (quoting important bits from there: class AutoArray { void * buffer; public: //Creates a new empty AutoArray AutoArray(); //std::auto_ptr copy semantics AutoArray(AutoArray&); //Note it can't be const because the "other" reference //is null'd on copy... AutoArray& operator=(AutoArray); ~AutoArray(); //Nothrow swap // Note: At the moment this method is not thread safe. void Swap(AutoArray&); }; ) Anyway, trying to implement the copy constructor. There's a piece of client code (not yet committed into bitbucket because it won't build) that looks like this:

Will auto_ptr be deprecated in incoming C++ standard? Should unique_ptr be used for ownership transfer instead of shared_ptr? If unique_ptr is not in the standard, then do I need to use shared_ptr instead? David Rodríguez - dribeas 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 inside

I heard auto_ptr is being deprecated in C++11. What is the reason for this? Also I would like to know the difference between auto_ptr and shared_ptr . 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 "fits" with the rest of the standard library considerably better (though, in fairness, some

I am confused with unique_ptr and rvalue move philosophy. Let's say we have two collections: std::vector<std::auto_ptr<int>> autoCollection; std::vector<std::unique_ptr<int>> uniqueCollection; Now I would expect the following to fail, as there is no telling what the algorithm is doing internally and maybe making internal pivot copies and the like, thus ripping away ownership from the auto_ptr: std::sort(autoCollection.begin(), autoCollection.end()); I get this. And the compiler rightly disallows this happening. But then I do this: std::sort(uniqueCollection.begin(), uniqueCollection.end());