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
