Adding objects to ListBox
Robert Chafer
Simple one this:
If I use ListBox1->Items->AddObject(... to associate an object to a
list box item, who owns the TObject? If I still own it how do I know
when it should be deleted?
Robert Chafer
John Croudy
Robert Chafer wrote:
> If I use ListBox1->Items->AddObject(... to associate an object to a
> list box item, who owns the TObject? If I still own it how do I know
> when it should be deleted?
This is a very important question and it crops up time and time again in
my head. I'm scared to delete things in case it causes a bug. I'm scared
to not delete things in case it causes a memory leak. I hate guessing.
It is extremely important to know who is responsible for deletion of
objects, but the help doesn't seem to care about it. My current project
is suffering from random access violations and this is probably caused
by me having to guess about deletion. Does anyone know the exact rules
about this kind of thing?
--
John Croudy <john....@semitechturku.cod> 'cod' should really be
'com'.
http://www.freepages.cban.com/pinkmouse/
The views expressed here are my own personal views and do not in any way
reflect the views of Semi-Tech (Turku) Oy.
Ralph Friedman (TeamB)
Robert:
If the object was created with an Owner parameter, the Owner will delete it
when the Owner is deleted, if it had no Owner, then you are responsible for
deleting it. The Objects array of TStrings (TListBox->Items) holds only a
pointer to the object. If you created it, you should know when it is
appropriate to delete it.
--
Regards
Ralph (TeamB)
Robert Chafer wrote in message <34ce7034...@news.demon.co.uk>...
>Simple one this:
>
>If I use ListBox1->Items->AddObject(... to associate an object to a
>list box item, who owns the TObject? If I still own it how do I know
>when it should be deleted?
>
>
>Robert Chafer
Oran Halberthal
Hi,
Ralph's rule isn't always true. For example objects in a TList have no owner
but still, TList does the delete job for you (The help explicitly mentions this
in this case).
I guess the rule should be: Unless documented and unless you have other
refersnces/pointers to some/all of the objects, delete them yourself.
(Another way is to check the VCL source to check if it does it or not).
Yet again, I too wish that the help files would have been more helpful in this
matter.
Hope this helps
Oran Halberthal
John Croudy
Oran Halberthal wrote:
> objects in a TList have no owner but still, TList does the delete job for you
> (The help explicitly mentions this in this case).
I know it deletes the array of pointers, but does it actually go and delete the
*objects* that are being pointed to? I hope not! When I add an object to a list, am
I giving the object to the list so that I no longer own it, or do I still own it
and have to delete it myself? I think the latter is true.
Ralph Friedman (TeamB)
Oran:
"TList does the delete job for you (The help explicitly mentions this >in
this case)."
That is a flat-out incorrect statement. TList deletes the space occupied by
the pointer in the instance of TList and that is all. It does not free
(delete) the instance that the pointer points to. Please show me where the
help "explicitly" contradicts this.
And please do it on this newsgroup, not via private email. (See newsgroup
guidelines, #8 at borland.public.announce)
--
Regards
Ralph (TeamB)
Oran Halberthal wrote in message <34CEEFC4...@netvision.net.il>...
>Hi,
>
>Ralph's rule isn't always true. For example objects in a TList have no
owner
>but still, TList does the delete job for you (The help explicitly mentions
this
>in this case).
>
Ralph Friedman (TeamB)
John:
You still have to delete it yourself. See my response to Oran.
--
Regards
Ralph (TeamB)
John Croudy wrote in message <34CEF759...@semitechturku.cod>...
Alain Naigeon
Ralph Friedman (TeamB) wrote:
>
> Oran:
>
> "TList does the delete job for you (The help explicitly mentions this >in
> this case)."
>
> That is a flat-out incorrect statement. TList deletes the space occupied by
> the pointer in the instance of TList and that is all. It does not free
> (delete) the instance that the pointer points to. Please show me where the
> help "explicitly" contradicts this.
>
> And please do it on this newsgroup, not via private email. (See newsgroup
> guidelines, #8 at borland.public.announce)
>
> --
> Regards
> Ralph (TeamB)
>
> Oran Halberthal wrote in message <34CEEFC4...@netvision.net.il>...
> >Hi,
> >
> >Ralph's rule isn't always true. For example objects in a TList have no
> owner
> >but still, TList does the delete job for you (The help explicitly mentions
> this
> >in this case).
> >
> >I guess the rule should be: Unless documented and unless you have other
> >refersnces/pointers to some/all of the objects, delete them yourself.
> >(Another way is to check the VCL source to check if it does it or not).
Yes, and of course it must be so, because we must be allowed to store
"the objects" (pointers to them) in more than one container. And then,
what would happen in each of them would delete the objects themselves ??
--
Alain NAIGEON - Strasbourg, France - anai...@club-internet.fr
"Le talent, c'est d'avoir envie de faire quelque chose" - Jacques Brel
Ralph Friedman (TeamB)
Alain Naigeon wrote in message <34CF13...@club-internet.fr>...
>Yes, and of course it must be so, because we must be allowed to store
>"the objects" (pointers to them) in more than one container. And then,
>what would happen in each of them would delete the objects themselves ??
>
stored in a TList (with appropriate typecasting), it could get interesting
if the TList tried to "delete" all of the integers that I stored in it.
--
Regards
Ralph (TeamB)
Robert Chafer
"Ralph Friedman (TeamB)" <rfriedman@spammenot_ibm.spammenot_net>
wrote:
> Robert:
>
> If the object was created with an Owner parameter, the Owner will delete it
> when the Owner is deleted, if it had no Owner, then you are responsible for
> deleting it. The Objects array of TStrings (TListBox->Items) holds only a
> pointer to the object. If you created it, you should know when it is
> appropriate to delete it.
Okay. Are you saying that if I actually stored TComponents and set
Owner to a form the objects would get deleted when the form was freed?
Robert Chafer
Steve Rogers
Oran Halberthal wrote:
>
> Hi,
>
> Ralph's rule isn't always true. For example objects in a TList have no owner
> but still, TList does the delete job for you (The help explicitly mentions this
> in this case).
TList only allocates memory for the void pointers it uses to store your
objects. In this respect, TList only "owns" the pointers to the objects
of the list, not the actual objects themselves.
This is why when I use TList, I always inherit from it. To do this, I
do the following:
1. I make a new Clear() method. The new Clear() method goes throught
each list member and deletes the object associated with Items[i]. Then
it calls TList::Clear().
2. I make a new destructor that calls the my derived clear method.
3. I might make a new Add method that takes maybe two or three
parameters, news the structure to hold the objects, and then stores the
object in the list. I also make a new Items property that retreives a
structure pointer. This saves lots of nasty type casting and makes the
code much more readable. For example:
typedef struct {
MetaCommandType mc;
int param;
} MetaCommand;
class TMetaCommandList : public TList
{
public:
// ctor
// dtor
void __fastcall Clear();
int __Add(MetaCommandType mc, int param = 0);
__property MetaCommand* MetaCommand[int index] = { read =
GetMetaCommand };
private:
MetaCommand* GetMetaCommand(int index)
{ return (MetaCommand*)Items[i];}
};
> I guess the rule should be: Unless documented and unless you have other
> refersnces/pointers to some/all of the objects, delete them yourself.
> (Another way is to check the VCL source to check if it does it or not).
The rule should be that you can delete an object but you should set it's
remaining pointer to 0 so that if something else deletes it, it can do
so without problems. In otherwords, if you are unsure who owns an
object "steal" it before you delete it.
> Yet again, I too wish that the help files would have been more helpful in this
> matter.
From the help for TList::Delete()
=============================================================
Note
Delete does not free up any memory associated with the item.
To free the memory that was used to store a deleted item,
set the Capacity property.
=============================================================
Comments:
"Delete does not free up any memory associated with the item." This is
poorly translated from Pascal. It should have said: Delete does not
delete the stored object, it simply removes it from the list and moves
other objects up to fill in the hole.
"To free the memory that was used to store a deleted item, set the
Capacity property." Again, poorly translated from Pascal. It should
have said: To delete the null pointers for previously deleted objects,
set the Capacity property equal to the Count property.
From the help for TList::Clear()
=============================================================
Call Clear to empty the Items array and set the Count to 0.
Clear also frees the memory used to store the Items array
and sets the Capacity to 0.
=============================================================
Comments: Poorly translated from Pascal. It should have said:
Clear deletes the memory used to store the pointers to objects
in the Items array, but does not call the destructor on these
pointers.
Paul Furbacher
Steve Rogers wrote:
> [...] In otherwords, if you are unsure who owns an
> object, "steal" it before you delete it.
Actually, that should read "before you _use_ it". By "stealing"
it, you are saying, I don't trust the owner not to delete it, so
I'll make a copy with the resolve to delete my copy later.
For those who live within the law, "stealing" means making a
"deep copy" the object. Typically, Assign() is a means for
making "deep" copy. A "shallow" copy is just a copy of the
pointer to the object.
Paul Furbacher
Paul Furbacher
From the on-line docs for TComponent::TComponent():
For components created manually, that is, not created
in the form designer, call TComponent and pass in an owner
component as the AOwner parameter. The owner will dispose
of the component when the owner is destroyed. If the
component is not owned, then call Free so that it is destroyed.
So, if we believe the docs, we can believe Ralph! Actually,
to test it, you could quickly create a descendent of TComponent,
override its Free() method, put a MessageBox() in there, and if
indeed the owner takes care of deallocation, well ....
Paul Furbacher
Ralph Friedman (TeamB)
Robert Chafer wrote in message <34cfb81...@news.demon.co.uk>...
>Okay. Are you saying that if I actually stored TComponents and set
>Owner to a form the objects would get deleted when the form was freed?
Robert:
Correct
--
Regards
Ralph (TeamB)
Oran Halberthal
Hi all,
Huh.... Thanks all for the verifications
I guess that the sentence in the Help:
~TList frees the memory used to store the list of items.
got me all confused, I guess that Borland should really make the Help files
clearer.
Bye
Oran Halberthal
Ralph Friedman (TeamB) wrote:
> Robert:
>
> If the object was created with an Owner parameter, the Owner will delete it
> when the Owner is deleted, if it had no Owner, then you are responsible for
> deleting it. The Objects array of TStrings (TListBox->Items) holds only a
> pointer to the object. If you created it, you should know when it is
> appropriate to delete it.
>
John Croudy
Oran Halberthal wrote:
> I guess that Borland should really make the Help files clearer.
Yes, a lot of it seems to be badly translated from Delphi. I keep seeing things
like foo.bar when they should have written foo->bar
Bah!
John
Jean Cremers
Hello John Croudy,
>Robert Chafer wrote:
>> If I use ListBox1->Items->AddObject(... to associate an object to a
>> list box item, who owns the TObject? If I still own it how do I know
>> when it should be deleted?
>
>This is a very important question and it crops up time and time again in
>my head. I'm scared to delete things in case it causes a bug. I'm scared
>to not delete things in case it causes a memory leak. I hate guessing.
Maybe related... If I Assign() a TStringList to another TStringList,
does this second Stringlist only use the pointer from the first one,
or does it allocate memory for it's items on it's own? So should I
Clear() the second Stringlist before I delete it or not?
J.J.M. Cremers, jcre...@noord.bart.nl
Home of PlanetDance: http://huizen.dds.nl/~freerk/jean
Jonathan Arnold
> > I guess that Borland should really make the Help files clearer.
> Yes, a lot of it seems to be badly translated from Delphi. I keep seeing things
> like foo.bar when they should have written foo->bar
Another gotcha to be aware of in the Help docs is the use of the "Default"
property. I can't remember now where I saw this, but in a couple of
places they use something like:
Foo->Items[0] = ....
where, in C++, they have to use:
Foo->Items->Strings[0] = ....
or some such. Delphi has "Default" properties, while C++ doesn't.
+===================================================+
| Jonathan Arnold (mailto:jdar...@world.std.com) |
| Programmer Roger Wagner Publishing |
| http://world.std.com/~jdarnold |
+===================================================+
Robert Chafer
Paul Furbacher <p...@bilbo.bio.purdue.edu> wrote:
> So, if we believe the docs, we can believe Ralph! Actually,
> to test it, you could quickly create a descendent of TComponent,
> override its Free() method, put a MessageBox() in there, and if
> indeed the owner takes care of deallocation, well ....
>
Tried it.... Works like a dream! Many thanks for you help (that goes
for everyone on this thread).
Robert Chafer
John Croudy
Jonathan Arnold wrote:
> Delphi has "Default" properties, while C++ doesn't.
So THAT explains it! No wonder I couldn't get the examples to work! <snarl>