Both seem to be able to offer better cleaner way to deal with pointers that has been introduced in C but when are you going to use one over the other?
Printable View
Both seem to be able to offer better cleaner way to deal with pointers that has been introduced in C but when are you going to use one over the other?
As far as I know the auto pointer is a smart pointer.
See Using auto_ptr effectively.
- petter
Yes, auto_ptr is smart pointer, and there are various libraries with different features - perhaps you're thinking of boost.
Here's the general idea.
A smart pointer can have features as simple as a stand in for a native pointer, with only the feature of automatic deletion when the auto_ptr falls out of scope, to a full featured reference counting ownership scheme.
One primary reason for wanting to use a smart pointer is containment. You can't forget to delete memory allocated into the pointer, because the auto_ptr is used either as a stack (local) variable, or a member variable - and therefore falls out of scope 'naturally' - and will delete (the final act of containment) the object it's 'holding'.
If that's the only purpose for a particular context, then the simplest version offers the best performance.
A more feature rich smart pointer that has reference counting ownership does the same thing, but can be used in threading contexts, or where use by multiple containers is required. If you allocated a structure, and pass that structure to a thread for processing, you create the question of 'who owns this object - who delete's it?' You can assume the thread should delete it, but what guarantee's that as code is modified over time? If, for example, that thread had a future modification which, by virtue of another queue, this object was placed in another thread's processing - like a chain of processes the object is passed through. In this context, it's not clear who should delete the allocated object. Reference counted smart pointers solve this problem to the point the programmer need no longer consider it. Whichever is 'last' automatically 'knows' that, and deletion occurs then.
So, you choose the version that supports the least feature set you need for a given context. If you're going to allocate a 'new' object, use it, then let it go - and for some reason that MUST be done as an allocated, and not a stack (local) object - then using the simplest auto_ptr makes the behavior similar to a stack object - it's basically a RAII paradigm.
A vector of pointers to an object is better constructed as a vector of auto_ptrs to those objects, as you won't have to 'run though and delete' every entry when the vector falls out of scope.
If, for some reason, you want a vector of pointers, and still wish to be able to 'pluck' one or two entries out of the vector, let the vector fall out of scope, but still USE the selected objects - you want a vector of reference counted smart pointers.
One problem with typical reference counted smart pointers is the very rare construction of a circular reference. If it is even possible that a smart pointer of this type in object A refers to object B, and object B also has one that referse back to object A, then these two objects 'hold onto each other' - and will be a memory leak. This is solved, usually, by invoking a weak version of the smart pointer such that the circular reference is broken. This condition rarely occurs.
You can not have a vector of auto_ptrs (fails the "assignable"Quote:
Originally Posted by JVene
requirement). Trying to use one shopuld not even compile,
but some allow it.
I see.
I'm not that familiar with boost - I was thinking of a series of smart pointer classes I use that are similar, and the simplest pointer in that library can be constructed as a vector.
smart pointer is a general term for all the smart pointers of which auto_ptr is just another type. auto_ptr cannot be used with array-type allocations. For that you would need something like boost::scoped array or you can simply make on of your own along the lines of std::auto_ptr with the required delete calls of the form delete[].In that case, what is the simplest smart pointer that you use?Quote:
Originally Posted by JVene
The library I use was started within a day (perhaps hours?) of when the first compilers were available for AIX (Unix) that supported templates.
The smart pointers I made at that time were of two forms, one called a shadow_ptr, the other a meta_ptr. The shadow_ptr was usable in vector containers (this was years before the STL was available), and was basically a simple stand in for the standard pointer with automatic deletion, automatic 'null' initialization and no reference counting. The meta_ptr had full reference counting, and was compatible with nodes used in trees and linked lists of the container series. I think most of us using C++ were cobbling together similar stuff in those days.
As previously stated, most compilers will not even let you compile a vector of auto_ptr.Quote:
Originally Posted by JVene
A vector of pointers to an object is better constructed as a vector of auto_ptrs to those objects, as you won't have to 'run though and delete' every entry when the vector falls out of scope.
Even compilers that do allow you to compile it, will usually fail to compile as soon as you add code that tries to add content to the container.
For more about smart pointers, check out the following link:
http://axter.com/smartptr/
If you're storing a container of smart pointers that's pointing to an abstract class, you should try using a clone smart pointer, as listed in above link.
Axter,
I think you missed my response to exterminator and Philip Nicoletti.
I don't use auto_ptr, and my original post was on a generic notion, not specifically about boost, which was my original error.
I assure you, all of the smart pointers in my library have been used in vector containers, but indeed, I've not used auto_ptr from boost.
Didn't quite answer me. I will rephrase it - how is this shadow pointer different from auto_ptr?Quote:
Originally Posted by JVene
auto_ptr is standard for quite some time ( part of std::, not boost:: ).Quote:
Originally Posted by JVene