Important
Please remember that std::auto_ptr
has many drawbacks and you generally should use std::unique_ptr
instead, if your compiler provides it. (If it doesn't, update your compiler! :))
Now back to your question...
Whats the sense of using this auto_ptr? It call the class destructor when getting out of scope as normal class initialize variable (a)
Exactly. The reason for auto_ptr
is to enforce strict ownership semantics- so that the object is properly destroyed when the pointer itself is destroyed.
I can't pass this pointer to a function with class pointer (func)
You can, you need to use get()
to look up the raw pointer. Using get()
when passing the pointer onto a function call means that the function is not going to take ownership of the object (the auto_ptr
still owns it and expects it to be still valid after the function returns).
Alternatively, you can use release()
on the pointer to obtain the raw pointer AND indicate that the auto_ptr
is no longer responsible for the ownership of the object.
I cant use pointer auto_ptr for A[] or char[] because auto_ptr calls delete not delete[]
Yup, that's an issue. That's one of the reasons why no longer use auto_ptr
since unique_ptr
was introduced. It does the same thing, but is safer (= easier) to use and more versatile.
The only think is that I dont have to write delete, but whats the sense of pointer if it will be destoyed when I get out of scope.
So that you won't forget it :-) Or you can use the auto_ptr
(or better unique_ptr
as a member in a class object).
but tell me what is the sense of using the auto_ptr rather then normal pointer?
Long story short: Many pointers can point to a single objects. All kinds of smart pointers exist to use the type system for bookkeeping which pointer owns the object (= is responsible for releasing it).
A side note
If you have a class which (may) own an instance of another object, you simply write:
class X {
// ...
X() : ptr(new Type()) {}
X(Type ptr) : ptr(ptr) {}
// ...
void setPtr(Type ptr2) { ptr.reset(ptr); }
// ...
std::unique_ptr<Type> ptr;
};
If ptr
is set, then for example unique_ptr
's destructor will take care of deleting the object (if there is one). In the setPtr
method, the reset()
function will delete the old instance (if there is one) and set the member to the new instance provided (or null - that's OK).
Now compare another situation:
class X {
// ...
X() : ptr(new Type()) {}
X(Type ptr) : ptr(ptr) {}
// ...
void setPtr(Type ptr2) {delete ptr; ptr = ptr2;}
// ...
Type* ptr;
};
Same behaviour? No! Because now, to have safe C++ code, you additionally need to write a destructor to delete ptr
when X
is destroyed.
OK now? NO! Because since you have a common destructor, you need to roll up (or block) your own copy constructor and assignment operator, because otherwise you might end up with two instances of X pointing to the same Type object- and both instances would here think that they own this instance and both would sometime try to delete it. Boom, access violation.
Unique_ptr won't allow you to implicitly copy the X object along with the strong reference to ptr
, because an unique_ptr is non-copiable (it believes that it is the only unique_ptr to the object, so it's the only smart pointer instance responsible for deleting it - but it's OK if raw, non-owning pointers point to it, as long as they don't try to delete something they don't own!).
And this is not all- unique_ptr can't be copied, but it has a move constructor and a move assignment operator ready for you! Hence you can safely return it from functions, et cetera.
This is how type safety of smart pointers translate to writing safer code.
A golden rule: try to avoid writing "delete" (unless you're writing your own containers or smart pointers). :)
). It's easy and nice to use once you read how it works. – Kos Oct 23 '11 at 17:54