How does c++ auto_ptr relate to managed pointers (Java, C#...)_问答_开发者

I come from a managed world and c++ automatic memory management is quite unclear to me

I开发者_JAVA技巧f I understand correctly, I encapsulate a pointer within a stack object and when auto_ptr becomes out of scope, it automatically calls delete on the pointed object?

What kind of usage should I make of it and how should I naturally avoid inherent c++ problems?

auto_ptr is the simplest implementation of RAII in C++. Your understanding is correct, whenever its destructor is called, the underlying pointer gets deleted.

This is a one step up from C where you don't have destructors and any meaningful RAII is impossible.

A next step up towards automagic memory management is shared_ptr. It uses reference counting to keep track of whether or not the object is alive. This allows the programmer to create the objects a bit more freely, but still not as powerful as the garbage collection in Java and C#. One example where this method fails is circular references. If A has a ref counted pointer to B and B has a ref counted pointer to A, they will never get destructed, even though no other object is using either.

Modern object orianted languages use some sort of variation of mark and sweep. This technique allows managing circular references and is reliable enough for most programming tasks.

Yes, std::auto_ptr calls delete on its content when it goes out of scope. You use auto_ptr only if no shared ownership takes place.
auto_ptr isn't particularly flexible, you can't use it with objects created with new[] or anything else.

Shared ownership is usually approached with shared pointers, which e.g. boost has implementations of. The most common usage, implemented e.g. in Boosts shared_ptr, employs a reference counting scheme and cleans up the pointee when the last smart pointer goes out of scope.
shared_ptr has one big advantage - it lets you specify custom deleters. With that you can basically put every kind of resource in it and just have to specify what deleter it should use.

Here's how you use a smart pointer. For the sake of example, I'll be using a shared_ptr.

{
    shared_ptr<Foo> foo(new Foo);
    // do things with foo
}
// foo's value is released here

Pretty much all smart pointers aim to achieve something similar to the above, in that the object being held in the smart pointer gets released at the end of the smart pointer's scope. However, there are three types of smart pointers that are widely used, and they have very different semantics on how ownership is handled:

shared_ptr uses "shared ownership": the shared_ptr can be held by more than one scope/object, and they all own a reference to the object. When the last reference falls off, the object is deleted. This is done using reference counting.
auto_ptr uses "transferable ownership": the auto_ptr's value can be held only in one place, and each time the auto_ptr is assigned, the assignee receives ownership of the object, and the assigner loses its reference to the object. If an auto_ptr's scope is exited without the object being transferred to another auto_ptr, the object is deleted. Since there is only one owner of the object at a time, no reference counting is needed.
unique_ptr/scoped_ptr uses "nontransferable ownership": the object is held only at the place it's created, and cannot be transferred elsewhere. When the program leaves the scope where the unique_ptr is created, the object is deleted, no questions asked.

It's a lot to take in, I'll grant, but I hope it'll all sink in soon. Hope it helps!

You should use boost::shared_ptr instead of std::auto_ptr.

auto_ptr and shared_ptr simply keep an instance of the pointer and because they are local stack objects they get deallocated when they go out of scope. Once they are deallocated they call delete on internal pointer.

Simple example, the actuall shared_ptr and auto_ptr are more sophisticated (they have methods for assignment and conversion/access to internal pointer):

template <typename T>
struct myshrdptr
{
    T * t;
    myshrdptr(T * p) : t(p) {}
    ~myshrdptr()
    {
        cout << "myshrdptr deallocated" << endl;
        delete t;
    }

    T * operator->() { return t; }
};

struct AB
{
    void dump() { cout << "AB" << endl; }
};

void testShrdptr()
{
    myshrdptr<AB> ab(new AB());
    ab->dump();
    // ab out of scope destructor called
    // which calls delete on the internal pointer
    // which deletes the AB object
}

From somewhere else:

int main()
{
   testShrdptr();
   cout << "done ..." << endl;
}

output something like (you can see that the destructor is called):

AB
myshrdptr deallocated
done ...

Rather than trying to understand auto_ptr and its relation to garbage-collected references, you should really try to see the underlying pattern:

In C++, all local objects have their destructors called when they go out of scope. This can be harnessed to clean up memory. For example, we could write a class which, in its constructor, is given a pointer to heap-allocated memory, and in its destructor, frees this pointer.

That is pretty much what auto_ptr does. (Unfortunately, auto_ptr also has some notoriously quirky semantics for assignment and copying)

It's also what boost::shared_ptr or other smart pointers do. There's no magic to any of those. They are simply classes that are given a pointer in their constructor, and, as they're typically allocated on the stack themselves, they'll automatically go out of scope at some point, and so their destructor is called, which can delete the pointer you originally passed to the constructor. You can write such classes yourself. Again, no magic, just a straightforward application of C++'s lifetime rules: When a local object goes out of scope, its destructor is called.

Many other classes cut out the middleman and simply let the same class do both allocation and deallocation. For example, std::vector calls new as necessary to create its internal array -- and in its destructor, it calls delete to release it.

When the vector is copied, it takes care to allocate a new array, and copy the contents from the original one, so that each object ends up with its own private array.

auto_ptr, or smart pointers in general, aren't the holy grail. They don't "solve" the problem of memory management. They are one useful part of the recipe, but to avoid memory management bugs and headaches, you need to understand the underlying pattern (commonly known as RAII) -- that is, whenever you have a resource allocation, it should be tied to a local variable which is given responsibility for also cleaning it up.

Sometimes, this means calling new yourself to allocate memory, and then passing the result to an auto_ptr, but more often, it means not calling new in the first place -- simply create the object you need on the stack, and let it call new as required internally. Or perhaps, it doesn't even need to call new internally. The trick to memory management is really to just rely on local stack-allocated objects instead of heap allocations. Don't use new by default.

Choose an imperative language (such as C, C++, or ADA) that provides pointer types.

Redesign that language to abolish pointer types, instead allowing programmers to define recursive types directly.

Consider carefully the issue of copy semantics vs reference semantics. Implement an interpreter for the language using DrRacket .