ownership of memory in stl containers??

[Khalid]

II am allocating alot of memory for my problem model which uses stl containers
for these pointers,
will stl free the memory?

by other words what is the semantics of memory ownership in stl?

thanks a lot

kh

 

[John Harrison]

II am allocating alot of memory for my problem model which uses stl containers
for these pointers,
will stl free the memory?
No.


by other words what is the semantics of memory ownership in stl?

You allocated it, you free it.

STL always operates on a copy of whatever you give to it. However a copy of
a pointer is just a pointer.

It actually much better to avoid raw pointers and the STL. Maybe you should
conisder using a smart pointer instead?

thanks a lot

kh

john

 

[Dave]

STL will free the memory *it* allocates to store your pointers. However,
you are responsible for deallocating the memory your pointers point to. STL
can't possibly know to free that memory because, for all STL knows, your
pointers could be pointing to memory that was not dynamically allocated.

If you want the deallocation of your memory to happen automatically, you
might consider using a smart pointer rather than a pointer. STL *will* call
the destructor of the elements it holds if those elements are of class type.
In the case of a smart pointer, that destructor call would result in the
deallocation of your memory (though, again, STL is not doing it directly).

HTH,
Dave

 

[Thorsten Ottosen]

"Khalid" <[email protected]> wrote in message

It actually much better to avoid raw pointers and the STL. Maybe you should
conisder using a smart pointer instead?

yes, for now you should use boost::shared_ptr.

Alternatively you might look at my library (which is in the review queue at
boost) at
http://cvs.sourceforge.net/viewcvs.py/boost-sandbox/boost-sandbox/boost/ptr_container/
http://cvs.sourceforge.net/viewcvs.py/boost-sandbox/boost-sandbox/libs/ptr_container/doc/

br

Thorsten

 

[David Rubin]

STL always operates on a copy of whatever you give to it. However a copy of
a pointer is just a pointer.

It actually much better to avoid raw pointers and the STL. Maybe you should
conisder using a smart pointer instead?

I've seen this suggested many times, but I've never read enough to
understand the benefits. My impression is that a "shared pointer" is an
object which encapsulates a pointer to the "real data." A copy of this
object is stored in the STL container. Since the container holds an
object (versus a pointer), the object destructor is called when the
container element is erase()d, and hence the real object is delete'd.
This is superior to storing raw pointers for which the caller must a)
hold a reference and coordinate object cleanup, or b) leak memory. Is
this at all accurate?

/david

 

[John Harrison]

I've seen this suggested many times, but I've never read enough to
understand the benefits. My impression is that a "shared pointer" is an
object which encapsulates a pointer to the "real data." A copy of this
object is stored in the STL container. Since the container holds an
object (versus a pointer), the object destructor is called when the
container element is erase()d, and hence the real object is delete'd.

Different smart pointers have different benefits. But for this situation
reference counting would be used which means that the real object would only
be deleted when the destructor for the last copy of the smart pointer is
invoked. This has many benefits whether or not those smart pointers happen
to be in STL container. Boost's shared pointer works like this (I guess
that's what makes it a _shared_ pointer).

This is superior to storing raw pointers for which the caller must a)
hold a reference and coordinate object cleanup, or b) leak memory. Is
this at all accurate?

Not quite sure what you mean by hold a reference, but the rest seems
accurate enough. For me the big problem in holding raw pointer in STL
containers is that you can manage it easily enough if you have only a single
copy of the container but a soon as you start to want to make copies of the
container things rapidly get too complex and messy.

john