You said below: "You know the admonition about increasing a
string's length by one
character at a time? The same goes for dynamic arrays."
But no, I don't believe I ever heard about that? Your analogy of an
array to variables is a great way of putting it though. I wish they used
that in the books on the subject I'd read some years ago, as I remember it
their explanation was somewhat convoluted!
Last night I tried your trick with TClassList, and you're
right...except that using Find/Replace it only took me 5 minutes! <g> I'm
definetly going to use this the next time I need to keep track of a set of
objects. Being that in this particular case I can better deal with my needs
using TComponents however, I'm just going to write a descendant of the
Tabcontrol as outlined in my reply to Cosmin.
from Robert Meek dba Tangentals Design CCopyright 2006
"When I examine myself and my methods of thought, I come to the conclusion
that the gift of Fantasy has meant more to me then my talent for absorbing
positive knowledge!"
Albert Einstein
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Rob Kennedy
Sent: Saturday, March 04, 2006 6:48 PM
To: Borland's Delphi Discussion List
Subject: Re: Objects and Lists...addendum
Robert Meek wrote:
> I got to thinking however that unless I actually needed to include
> methods in this object type, I might be better off using a record instead.
> Am I correct in that a record having the same number and type of
properties
> as does an object uses a lot less memory?
No. An instance of a class will occupy only four bytes more than an
instance of a record with the same fields. The difference might increase
if the record is packed, but since this is something you're only
planning to store in memory, and not on disk, I don't recommend packing
the records anyway.
In addition to the per-instance cost of four bytes, there's also the
class's VMT, but the size of that is constant, not based on how many
instances of the class there are.
> but it seems to me that it involved creating
> a wrapper class around the TObjectList so one could write code like this
> where the object type the list is holding is a TMemo:
Writing a wrapper for a list class is easy. It doesn't take more than 15
minutes. Copy Contnrs.TClassList, change its base class to TObjectList,
and replace all occurrences of "TClass" with whatever you call your class.
> First of all, I realize Dynamic Arrays are not really dynamic in the
> same sense as strings are in that they won't simply grow in size as
required
> without the programmer's help.
Neither will strings. Strings only grow when you tell them to.
The key difference between dynamic arrays and long strings is that the
"+" operator isn't defined for arrays. The Length and SetLength
functions work the same.
> Using Setlength is what does the trick, and
> one can call it anytime you need to increase the number of fields required
> by the array.
Arrays don't have fields. They have elements. Records have fields.
> And I'm guessing the compiler figures out just how much
> memory is required for each field based upon the type of object being
placed
> into them.
Yep. Just like strings.
> So if I create an array is ii okay to set its length at the start to
> just 1?
Sure. Why not? It started off with length zero.
> I tried it and it compiles and runs okay but I wondered if there
> might be something else that would make doing so a bad idea?
It's no different from having a string of length 1.
> Now when I need to create a new page in the editor, I first create
> the new tab, then a new instance of the object type I wrote, and then I
call
> SetLength and increment its current length to hold another object, and
> finally I assign the object to the array.
You know the admonition about increasing a string's length by one
character at a time? The same goes for dynamic arrays.
> When I'm ready to close the editor, I must first free and nil each
> instance of my object that I had created at runtime, correct?
You need to free the objects. You can't nil an object. You can only nil
a reference to an object, but it's only worth doing that if you're going
to check the value of that reference later.
> But what if
> when I create each object I set the form as the object's owner? Would
they
> then be freed like any other component when the form itself is freed?
If your class descends from TComponent, then it will inherit all the
behaviors of TComponent, including the ability to be owned by other objects.
> What
> about making the object's owner the array itself? Is this possible and
> would there be any advantage or disadvantage to doing so?
Arrays aren't objects in Win32. See my comments regarding TObjectList below.
> And finally, is
> it true that no matter how many fields an array might contain, simply
> setting the array to nil will free it properly, or do I have to iterate
thru
> and delete each field first?
Assigning nil to a dynamic-array variable is the same as setting its
length to zero. They are completely equivalent operations.
You do not need to decrease the array's length one by one.
> Is there anyway, like with an ObjectList, to
> make the array responsible for the objects it references?
No. That's why we have TObjectList.
An array is nothing more than a group of like-typed variables that all
go by the same name. If you can't get a regular standalone variable to
be responsible for the object it refers to, then you can't get a group
of them to be responsible, either.
--
Rob
_______________________________________________
Delphi mailing list -> [email protected]
http://www.elists.org/mailman/listinfo/delphi
_______________________________________________
Delphi mailing list -> [email protected]
http://www.elists.org/mailman/listinfo/delphi
