«

Silly question maybe...
I pass a refrence to an object to a method...
The method adds the object to a (stl) list of these objects...
However if a refrence to the object is passed and then added list...
if the original object is destroyed.. is the object in the list invalid
or is a copy of the object
made by the stl list for insertion purposes

JustSomeGuy wrote:

> Silly question maybe...
> I pass a refrence to an object to a method...
> The method adds the object to a (stl) list of these objects...
> However if a refrence to the object is passed and then added list...
> if the original object is destroyed.. is the object in the list
> invalid or is a copy of the object
> made by the stl list for insertion purposes

The list contains a copy of the object, so destroying the original won't
affect the list.

"JustSomeGuy" <> wrote in message
news:...
> Silly question maybe...
> I pass a refrence to an object to a method...
> The method adds the object to a (stl) list of these objects...
> However if a refrence to the object is passed and then added list...
> if the original object is destroyed.. is the object in the list invalid
> or is a copy of the object
> made by the stl list for insertion purposes
>

In the container classes of the standard library copies of the passed
objects are inserted. But you can easily try & check this yourself.

HTH
Chris

On Tue, 29 Jun 2004 11:28:09 -0600, JustSomeGuy <>
wrote:

>Silly question maybe...
>I pass a refrence to an object to a method...
>The method adds the object to a (stl) list of these objects...
>However if a refrence to the object is passed and then added list...
>if the original object is destroyed.. is the object in the list invalid
>or is a copy of the object
>made by the stl list for insertion purposes

You cannot create containers of references, only of objects or
pointers.

If you allocate memory for an object with "new" and store a pointer to
that object in an STL container, you need to ensure that you call
"delete" on every pointer before the container is cleared.

--
Bob Hairgrove

"Bob Hairgrove" <wouldnt_you_like@to_know.com> wrote in message
news:...
[SNIP]
>
> If you allocate memory for an object with "new" and store a pointer to
> that object in an STL container, you need to ensure that you call
> "delete" on every pointer before the container is cleared.
>

This is not necessarily true. The standard library containers also create
copies of pointers and it depends very much what you want to achieve whether
a delete statement should/must be issued before the container is cleared.
Imagine for example a container of pointers to geometric primitives and
another container where you store the pointers to the subset of the
primitives that have been selected. If you called a delete statement on the
pointers in the selection container then you´d send all those primitives
into nirvana which is certainly not what you normally would want.

Cheers
Chris

On Tue, 29 Jun 2004 21:42:34 +0200, "Chris Theis"
<> wrote:

>
>"Bob Hairgrove" <wouldnt_you_like@to_know.com> wrote in message
>news:.. .
>[SNIP]
>>
>> If you allocate memory for an object with "new" and store a pointer to
>> that object in an STL container, you need to ensure that you call
>> "delete" on every pointer before the container is cleared.
>>
>
>This is not necessarily true. The standard library containers also create
>copies of pointers and it depends very much what you want to achieve whether
>a delete statement should/must be issued before the container is cleared.
>Imagine for example a container of pointers to geometric primitives and
>another container where you store the pointers to the subset of the
>primitives that have been selected. If you called a delete statement on the
>pointers in the selection container then you´d send all those primitives
>into nirvana which is certainly not what you normally would want.

You are quite correct ... of course, it is a question of who "owns"
the memory allocated for the pointers. In most cases I have seen, it
will be whatever is controlling the container, though (or perhaps some
other container higher up in a certain application-defined hierarchy,
as you suggest). The OP's question seemed to indicate that it was an
issue to be pointed out.

--
Bob Hairgrove