Auto_ptr = pointers for dummies?

Howdy,

As some of you may know, I'm hopeless when it comes to pointers. Today I was reading though an article at http://www.relisoft.com/resource/index.htm, and it mentioned auto_ptr. From what I can gather, auto_ptr seems to be like a pointer for newbies. For what I understand, as soon as it goes out of scope it gets deleted automatically, like javas garbage collector but without the overhead. Is this so?

Since I don't understand pointers very well, would it be safer for my program if I used auto_ptr? In what cases would I use a regular pointer rather than auto_ptr? And finally.. Should I bother calling delete on a pointer created by auto_ptr, or just leave it to go out of scope. And if I should delete it, how would I go about doing so?

Thanks for any information!

I do'nt know much about that stuff as I don't use such high level things. I just prefer to stick with my pointers. ^^
But, in C++, you can almost get rid of all pointers, just use auto_ptr and containers and you're done.
But, auto_ptr have the disavantage that they do delete everything they hold, even if other pointers are pointing to them.

[edit]Oh, and, some advice, learn pointers!! I like them, even if you do'nt use them, you'd better know how everything work.

Thanks for the reply lyx, I don't know what I'd do without you :) It seems you've replied to almost every thread I've posted lately, thanks :D

I know I should learn pointers properly.. I think I'm getting there but I don't trust my knowledge of them 100% to use them in a project, thats why I'd prefer something like auto_ptr. Being self taught and limited access to proper books makes it hard to teach myself something complicated, although its the highest thing on my priority list when I get some formal classes (like going to uni).

Now I have a question. When passing an auto_ptr to a function is there any differences? Say I have something like this:

Code:

---

class SOMETHING
{
  [..]
}:

int FunctionThatManipulatesSomething(SOMETHING * Something);

---

Where normally I would call FunctionThatManipulatesSomething with an address of a local SOMETHING instance so that FunctionThatManipulatesSomething can manipulate it. Would I have to change anything there?

There is a huge difference.

The thing is, the second statement below changes *both* ptr2 and ptr1.

std::auto_ptr<MyClass> ptr1(new MyClass());
std::auto_ptr<MyClass> ptr2 = ptr1;

There is a better smart pointer (boost::shared_ptr, but you need to understand pointers before you start hiding them in wrappers.

Well, I'll tell you something, stovellp; I didn't understand *well* (better than you at present do, but, not enough) pointers until I do some ASM work, where I learn a lot of things; if you don't fear the low level stuffs, you should do as well.

Quote:

---

Originally posted by lyx
... just use auto_ptr and containers and you're done...

---

Lots of good advice here but I had to specifically point out that one big reason Cat wants you to check out boost::shared_ptr is that you should never use auto_ptr with the STL containers.

auto_ptr with STL containers? You mean, at the same time? or a auto_ptr that points to a container? or a container that contains auto_ptr?

And, I don't know about STL so, if I said something wrong... just correct me.

[edit]I was just saying that containers and smart pointers can make real ones way less useful.

Don't worry lyx, I wasn't specifically correcting you. Containers and auto_ptrs are both very helpful like you said. What I meant was you should never have a container of auto_ptrs. For example:

std::vector<std::auto_ptr<int> >

is a bad idea because the auto_ptr when copied copies the "ownership" of the pointer. The STL containers do a lot of copying, and eventually the wrong object will have ownership of the pointer and delete it at the wrong time.

The boost::shared_ptr is reference counted, so it can be copied safely without mucking with ownership, since ownership is shared between all copies.

Well, fine with me, I just don't know that part of the standard so I don't bother being corrected.

Quote:

---

Originally posted by jlou
Don't worry lyx, I wasn't specifically correcting you. Containers and auto_ptrs are both very helpful like you said. What I meant was you should never have a container of auto_ptrs. For example:

std::vector<std::auto_ptr<int> >

is a bad idea because the auto_ptr when copied copies the "ownership" of the pointer. The STL containers do a lot of copying, and eventually the wrong object will have ownership of the pointer and delete it at the wrong time.

The boost::shared_ptr is reference counted, so it can be copied safely without mucking with ownership, since ownership is shared between all copies.

---

Most good STL implementations actually are cleverly written such that making a container of auto_ptr will not compile, but yes, you can never use a container of auto_ptr.

It is legal to use an auto_ptr to hold a pointer to a container, though.

The reason you can't use auto_ptr is that the auto_ptr objects don't met the copy criterion. That is, if you do this code for some objects a and b:

a = b;

the copy criterion says that, to the user of the objects, a and b should be identical. This is not true with the auto_ptr -- only one auto_ptr may "own" a dumb pointer, and so when one acquires it (in the line above, a acquires the pointer of b), the other loses it.