STL destruction question...

When a STL container is destroyed, will the destructor of the individual
objects be automatically called?

re: STL destruction question...

barcaroller wrote:Yes, assuming they have one!

--
Ian Collins.

re: STL destruction question...

"Ian Collins" <ian-news@hotmail.comwrote in message
news:58t3hhF2i6eqtU23@mid.individual.net...Does this also apply to object pointers (e.g. set<Class*>)? In this case I
would create the object myself (using 'new Class') but I assume that, since
I created it, I should destroy it. However, there's no reason why the STL
container could not do that for me (by calling delete for each object).
Would it?

re: STL destruction question...

barcaroller wrote:It will not and, if you consider it for a moment, you'll probably agree
that it should not.

re: STL destruction question...

"barcaroller" <barcaroller@music.netwrote in
news:f0blum$j15$1@aioe.org:
Follow the logic rigidly. The destructors of the contained object are
called. The contained object is a Class*. The destructor for a Class* (or
any other pointer for that matter) is a no-op. You may wish to consider
using some sort of smart pointer class (but specifically not std::auto_ptr)
as the contained object. This way the contained object is a smart_ptr
<Class>, and thus ~smart_ptr<Class>() would be invoked. Or you could loop
over the container and delete each pointer by hand.

re: STL destruction question...

On 21 Apr, 01:30, "barcaroller" <barcarol...@music.netwrote:That's one way of obtaining a Class*. Another way is to take the
address of an existing Class object - which may or may not have
dynamic storage duration (i.e. may or may not need delete'ing).
Absolutely.
STL containers could have been designed that way. But such behaviour
would rule out the possibility of storing pointers to anything other
than dynamically allocated memory. The code below would be broken -
something of a restriction on the way STL containers could be used.

#include <vector>

void foo()
{
int i = 42;
int* pi = &i;
std::vector<int*v;
v.push_back(pi);
}
Nope. The library designers opted not to impose the above restriction
on client code. You were right in your first assumption.

If you are storing pointers to dynamically allocated objects, you can
make your life easier by storing smart pointers that manage the delete
automatically. Boost has examples and I believe some are included in
std::tr1 if your compiler supports it.

Gavin Deane

re: STL destruction question...

On Apr 21, 2:30 am, "barcaroller" <barcarol...@music.netwrote:(Formally, all objects have destructors. Some destructors are
trivial, however.)
Of course. The pointer gets destroyed. (Of course, the
destructor of a pointer is trivial, so nothing much really
happens.)

The library does not persue pointers. Luckily, because in a lot
of cases, the set<Class*is used for navigation, and there are
still a lot of other pointers to the objects when the set gets
destructed.
Correct.
Only that it would break most common uses of sets of pointers.
It's really fairly rare for a container to have ownership of a
non-value object.

--
James Kanze (Gabi Software) email: james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34