I don't *have* to keep track of TLinks, do I?
BlitzMax Forums/BlitzMax Beginners Area/I don't *have* to keep track of TLinks, do I?
| ||
| Normally I always store my TLinks when working with TLists. It makes it fast for me to remove items from the list, for one thing. But let's suppose I have a list which is populated at creation and never has any more added or any taken away. All I'll ever need to do is cycle through everything on the list. Now when the object which holds this list dies or no longer needs the list, I can just List.Empty() and I have no leaks, right? |
| ||
| right :) |
| ||
| Thanks, just getting a bit anal about memory leaks in my design here. I hate the code design stage, I always overthink things. |
| ||
| I always overthink things. If it helps, so does everyone else. |
| ||
| Use list.clear() to empty the list before you "null-ify" it (or before it goes out of scope). Otherwise it might give you a memory leak. |
| ||
| Gabriel: There is no Empty() method, I assume you meant Clear() which is what I use... Dreamora: Why does it need to be cleared if going out of scope? I mean, I'll probably clear it out of habit but surely the GC clears the pointers in it (to decide if any of the objects need to be freed as well) before nullifying the list pointer? In fact there was a recent thread about clearing arrays (so very similar) where just setting the array to null was deemed OK instead of looping and clearing out each element manually... |
| ||
| Why does it need to be cleared if going out of scope? It doesn't. Just make sure you don't use cyclic references. |
| ||
| "cyclic references". I can guess what this means but please elaborate or do you just mean it stops you from reusing the list which was never cleared out before? This shouldn't be an issue if it goes out of scope because it will be redeclared and allocated next time the function or whatever is entered. |
| ||
| Wrong. The problem is, theoretially the list should be cleared when it is "removed", thats what the delete method declares. Stupidly this one isn't called quite often (never?) which is most likely because BRL implemented the linked list as a double linked list in which the "core" link is always the same (first is corelink.next and last is corelink.prev and the corelink is double linked to both so the list "never ends). You can cycle endless in both directions, forward / backward without ever reaching an end. Due to that structure, if clear is not executed, the whole list (beside the TList reference that referenced to _head) will remain in RAM but you won't be able to get your hands on it anymore. As mentioned, clear is part of the delete method and should be called ... it should and thats the problem ... |
| ||
| blimey that's definitely worth knowing, thanks guys! |
| ||
| You can cycle endless in both directions, forward / backward without ever reaching an end. Is this true? I might have misunderstood but the following suggests no link from bottom of the list to the top. |
   |