> 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.
It requires a shift of thinking. I'm struck by your phrase, "You have to call... every time you wan to assign a new element to it." Of course if you need to expand the size of the array you are correct. But the phrase sounds strikingly similar to one you would expect to hear when talking about higher-level container classes and objects. An array is not such a beast. At its base it's really just a chunk of memory and you must consider using an array with that in mind. Of course with memory comes pointers and addresses and other such scaries. If you want a higher-level entity then look to the TList's and other containers but keep in mind they're using the same scary stuff under the covers and, in the end, somebody has to, they're the basic building blocks of all that we do. > At the same time, the array itself is typed so you can't use > it to hold more than one element type Well, that's not entirely true, but we hit that shift in thinking again. Certainly at its core is the idea of a homogeneous structure and at the very base the size of each sub-element /will/ be the same. As an aside, you do realize that you get to each array element with simple arithmetic right? You know, first element + size of the element type = the 2nd element. Of course there is the typecast, you are the one in charge right? But really, the easiest example is OO polymorphism which will let you store entire trees of different objects. That's the idea behind TObjectList right? And of course there's always the void pointer. > AND it automatically deallocates memory > if you delete an element! It only de-allocates memory if you resize the array. Is that what you mean by delete an element? Hard to tell, your phraseology sounds more fitting to a OO container class. So in interpreting, I'm going to have to go with actually deleting an element of the array, which can only be done by reallocation. So where's the rub, that's exactly what you'd expect right? :) > I don't consider that to be very dynamic, Well, historically you are right. When we used to refer to dynamic data structures this meant stuff that specifically wasn't array based. Linked Lists are so named specifically because elements do not exist in a single contiguous block of memory but are scattered wherever they may be and are simply linked together with references to each other. But attaching the dynamic adjective to array structures creates entirely new meanings. Delphi dynamic arrays and long strings are dynamic, array-like, structures. But dynamic or not, use them without considering memory allocation and de-allocation and you're missing the boat. Also keep in mind some advantages and disadvantages of contiguous memory structures and truly dynamic structures, the distinctions are very important. Arrays are fact to access and traverse, as I stated above, it's simple pointer arithmetic. Linked structures must usually be traversed over by following links. There are tricks and techniques for improving such things but in general, you get the idea. On the other hand, adding elements, removing elements, etc. with linked structures are trivially fast compared with reallocating an entire array just to insert a new element. And not just allocating a new array but copying everything over from the old array to the right place in the new array. Do you get the feeling one must consider a few things before a good decision can be made? I don't think Delphi has any truly dynamically linked container classes does it? I don't remember. Jim ------------------------------------------------------------------------ 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
