It's also one of the problems with not having any formal Comp sci
education! <g> I may not ever catch up to the rest of you on things like
this but it's a hell of a fun chase! And actually, I have used linked lists
before, having learned most about them from Bucknell's book on algorithms,
and one of our fair members constant use of pointers <bg>, but so far
haven't had need for a doubly-linked version. My only concern with using a
dynamic array was that I wasn't able to find a good explanation of exactly
what is or isn't dynamic about it. For example, if all objects going in are
of the same size all I need to worry about is that I can increase the size
or number of elements in the array, but what about individual object
properties such as long-strings which themselves are dynamic. Can a dynamic
array deal safely with objects that hold dynamic properties or variables by
themselves or do I have to deal with this in another way? From what I
gathered simple dynamic arrays can be looked at like Vars of a pointer to a
linked list when you get right down to it but with special built-in
functions making them easier to work with is some cases. And if that's true
that I needn't worry about such things and the overhead of their use in this
instance at least won't be a problem at all.
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 Rainer von Saleski
Sent: Wednesday, March 08, 2006 10:18 AM
To: Borland's Delphi Discussion List
Subject: Re: Objects and Lists...addendum -> Strings
Actually, you only need to call SetLength when you want to increase the
maximum size of the array. If you are adding elements in the middle of a
(sparse) array, you don't need to call SetLength.
One of the original motivations behind the "array of type" declaration was
to enable writing procedures that work with any size of array. And this
works very well. The ability to allocate arrays dynamically is sort of a
follow-on to that. It is needed to allow a procedure that handles array
arguments of non-pre-known size to allocate appropriately sized temporary
arrays for work space.
For piling on elements in a storage area that grows and grows, my
(pre-Delphi) favorite approach was a linked list. Keep pointers to the
beginning and end, and it is easy to add more elements; to traverse the list
in one direction; and to delete specific elements. If you really need to
traverse in both directions, make the list doubly linked. If you need to
"bookmark" an item, that's a pointer. I can't remember when I've ever
needed to access, say, the 43rd element in such a list (except to find the
median value).
Actually, you can use an array to hold elements of diverse types and sizes.
Simply declare an "array of pointer". And if you think about it, this is
what has to be done anyway if array elements are of varying sizes -- maybe
it's done behind the scenes for you, but the array itself MUST have elements
of identical size of you want to be able to calculate the address of an
element from the subscript.
One of the troubles with the compiler and the component library doing all
sorts of neat things for you is that there can be lots of hidden overhead in
what appear to be simple operations. Then you're left wondering why your
program runs slower than you expected, and you don't have a clue where to
look.
Rainer
----- Original Message -----
From: "Robert Meek" <[EMAIL PROTECTED]>
To: "'Borland's Delphi Discussion List'" <[email protected]>
Sent: Tuesday, March 07, 2006 10:43 AM
Subject: RE: Objects and Lists...addendum -> Strings
One of the points I was trying to make was that dynamic Arrays are
unlike ansi strings in the sense that with the latter Delphi handles the
allocation for you. It's a no-brainer. I can use the same string var over
and over no matter what the number of chars are that I need to stuff into
it. With dynamic arrays, this isn't true. You have to call
SetLength(array, Integer) every time you want to assign a new element to it.
At the same time, the array itself is typed so you can't use it to hold more
than one element type AND it automatically deallocates memory if you delete
an element! I don't consider that to be very dynamic, still though for the
need I have its benefits far outweigh those of an ObjectList.
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 Jim Burns
Sent: Monday, March 06, 2006 11:13 PM
To: 'Borland's Delphi Discussion List'
Subject: RE: Objects and Lists...addendum -> Strings
> No, don't know Delphi-Talk
> Yes, I am worried about the memory allocation stuff
> Yes, and fragmentation and
> Yes, I use a lot of string stuff
> So how can I deal efficiently with strings?
It isn't really any issue solely of strings per se. It's more about
understanding what is happening behind the scenes and when and how the
things you do in the language result in memory allocations and deallocations
and then determining if the task at hand is large or significant enough to
warrant a better approach.
If you use ansistrings, normally the default Delphi string, then they're
dynamic. What does this mean? You must understand this. Thus, unless you
take steps to the contrary, everytime you simply assign new values to such a
string, allocations and deallocations take place. Straight-forward.
The only alternative to this is to do things the way we used to, handle the
allocation yourself. Ex. Null-terminated strings, or more precisely, arrays
of chars, were important immediately because one could allocate once, a
large but reasonable array, write new data to the array of chars at any
time, stop by adding an ending null and never worry about junk data, never
worry about zeroing first, or clearing old data. As long as what you needed
fit inside your initial allocation, you used that array over and over
without worry. Oh you might have to write character by character, so macros
developed, null-terminated handlers, etc. But you could minimize
allocations.
Of course, there are reasons to prefer dynamic arrays as well. But
certainly not when one knows ahead of time that might involved a zillion
repetitive alloc/dealloc procedures.
Strings or arrays of whatever, lists of records or other binary data, it
makes no difference. It's simply a matter of understanding how to use,
request and release memory efficiently for what you're wanting to do.
With more efficient handling comes more work. You have to decide the
trade-offs. As the example that lead to this discussion demonstrated, the
down-side can be as bad as being literally dysfunctional; the upside can be
a performance boost beyond expectations.
Regards,
------------------------------------------------------------------------
Jim Burns, <mailto:[EMAIL PROTECTED]>
Technology Dynamics
Pearland, Texas USA
281 485-0410 / 281 813-6939
_______________________________________________
Delphi mailing list -> [email protected]
http://www.elists.org/mailman/listinfo/delphi
_______________________________________________
Delphi mailing list -> [email protected]
http://www.elists.org/mailman/listinfo/delphi
_______________________________________________
Delphi mailing list -> [email protected]
http://www.elists.org/mailman/listinfo/delphi
