VC STL - auto delete of pointers in std::list

Author

auto delete of pointers in std::list

Corey Wirun

2005-03-02, 9:00 pm

Yet another question to y'all:

If I'm adding heap objects to a std::list<T> (created on the heap): e.g:

for (int i = 0; i < 10; i++)
{
TObject * p = new TObject();
pColl->push_back(p);
}

I noticed that the list destructor appears to 'delete' the TObject pointers
when the std::list<T> itself is 'delete'd. In xmemory, I see executing:

void deallocate(pointer _Ptr, size_type)
{ // deallocate object at _Ptr, ignore size
operator delete(_Ptr);
}

Sure enough, _Ptr, is an instantiation of my TObject object.

Can this behavior be conditionally modified? I have a situation where a
std::list contains a copy of some (not all) ptr's from a master std::list
and I don't want to 'delete' these objects since it would blow away the
master list contents as well.

Thanks for all your help! You guys are great!
Corey.

Igor Tandetnik

2005-03-02, 9:00 pm

"Corey Wirun" <corey.wirun@nospam.ca> wrote in message
news:%23yEohV3HFHA.2620@tk2msftngp13.phx.gbl
> Yet another question to y'all:
>
> If I'm adding heap objects to a std::list<T> (created on the heap):
> e.g:
>
> for (int i = 0; i < 10; i++)
> {
> TObject * p = new TObject();
> pColl->push_back(p);
> }
>
> I noticed that the list destructor appears to 'delete' the TObject
> pointers when the std::list<T> itself is 'delete'd.

No it doesn't.

> In xmemory, I
> see executing:
>
> void deallocate(pointer _Ptr, size_type)
> { // deallocate object at _Ptr, ignore size
> operator delete(_Ptr);
> }

std::list uses this to free its own nodes, not the pointers it stores.

> Sure enough, _Ptr, is an instantiation of my TObject object.

What makes you think so?
--
With best wishes,
Igor Tandetnik

With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925

Corey Wirun

2005-03-02, 9:00 pm

> > void deallocate(pointer _Ptr, size_type)
>
> std::list uses this to free its own nodes, not the pointers it stores.
>
>
> What makes you think so?
> --

In the VS2002 debugger, in the above code, I can see _Ptr in the 'Locals'
debug pane, I expand the object and I see my TObject members. I watched
the address when the object was 'new'd and put into the list. Sure enough,
I see the same address above in the deallocate above.

Stepping into the 'operator delete(_Ptr)' it jumps over to dbgdel.cpp where
the memory is removed from the heap.

You sound surprised. Is this not what is supposed to happen? :)

C.

Corey Wirun

2005-03-02, 9:00 pm

Yikes! My mistake. Turns out the node that's being deleted has the pointer
only AS A PART OF IT, but you're right it appears it's deleting the node,
not the payload.

Ergh. Back to the books.

Thanks for the help, Igor.

C.

"Corey Wirun" <corey.wirun@nospam.ca> wrote in message
news:pjrVd.35228$ab2.26191@edtnps89...
>
> In the VS2002 debugger, in the above code, I can see _Ptr in the 'Locals'
> debug pane, I expand the object and I see my TObject members. I watched
> the address when the object was 'new'd and put into the list. Sure
enough,
> I see the same address above in the deallocate above.
>
> Stepping into the 'operator delete(_Ptr)' it jumps over to dbgdel.cpp
where
> the memory is removed from the heap.
>
> You sound surprised. Is this not what is supposed to happen? :)
>
> C.
>
>

Arnaud Debaene

2005-03-02, 9:00 pm

Corey Wirun wrote:
> Yet another question to y'all:
>
> If I'm adding heap objects to a std::list<T> (created on the heap):
> e.g:
>
> for (int i = 0; i < 10; i++)
> {
> TObject * p = new TObject();
> pColl->push_back(p);
> }
>
> I noticed that the list destructor appears to 'delete' the TObject
> pointers when the std::list<T> itself is 'delete'd. In xmemory, I
> see executing:
>
> void deallocate(pointer _Ptr, size_type)
> { // deallocate object at _Ptr, ignore size
> operator delete(_Ptr);
> }
>
> Sure enough, _Ptr, is an instantiation of my TObject object.

No : STL containers are value based, not pointer based : A std::list<T*>
does NOT delete the pointers it contains (otherwise, how would
std::list<int> work?). What you see is the deletion of the list's nodes, not
the deletion of the content of the nodes.

If you want a STL container to contain pointers and delete them on
destruction, you should use smart-pointers. boost::shared_ptr do the thrick
nicely (see www.boost.org) :
typedef boost::shared_ptr<T> TPtr; //smart pointer to T
std::list<TPtr> MyList;
MyList.push_back(TPtr(new T)); //object destoyed when MyList goes out of
scope.

Arnaud
MVP - VC

Jonathan Turkanis

2005-03-02, 9:00 pm

Arnaud Debaene wrote:

> No : STL containers are value based, not pointer based : A
> std::list<T*> does NOT delete the pointers it contains (otherwise,
> how would std::list<int> work?). What you see is the deletion of the
> list's nodes, not the deletion of the content of the nodes.
>
> If you want a STL container to contain pointers and delete them on
> destruction, you should use smart-pointers. boost::shared_ptr do the
> thrick nicely (see www.boost.org) :

Also, in the next release of Boost (I hope) Thorsten Ottosen's Pointer container
library will appear. This library provides versions of the standard containers
which perform lifetime management for dynamically allocated objects. Part of the
rationale is to reduce the overhead associated with containers of smart
pointers.

Jonathan

Sponsored Links