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
