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

barcaroller wrote:

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

Yes, assuming they have one!

--
Ian Collins.

"Ian Collins" <ian-news@hotmail.comwrote in message
news:58t3hhF2i6eqtU23@mid.individual.net...

barcaroller wrote:

Yes, assuming they have one!

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?

barcaroller wrote:

"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?
>

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

"barcaroller" <barcaroller@music.netwrote in
news:f0blum$j15$1@aioe.org:

>
"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?

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.

On 21 Apr, 01:30, "barcaroller" <barcarol...@music.netwrote:

"Ian Collins" <ian-n...@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')

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).

but I assume that, since
I created it, I should destroy it.

Absolutely.

However, there's no reason why the STL
container could not do that for me (by calling delete for each object).

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);
}

Would it?

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

On Apr 21, 2:30 am, "barcaroller" <barcarol...@music.netwrote:

"Ian Collins" <ian-n...@hotmail.comwrote in message

news:58t3hhF2i6eqtU23@mid.individual.net...

(Formally, all objects have destructors. Some destructors are
trivial, however.)

Does this also apply to object pointers (e.g. set<Class*>)?

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.

In this case I
would create the object myself (using 'new Class') but I assume that, since
I created it, I should destroy it.

Correct.

However, there's no reason why the STL
container could not do that for me (by calling delete for each object).
Would it?

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