While I admit that Max's memory management scheme is elegant in it's design, I am still struggling with it even after a month of using it because it is a NIGHTMARE to manage in practice.
Take this comment for example, which I need to have in my code to remind me that stuff will actually get freed when I free a path in my sprite system:
See what I mean?
Each point in my pointlist points back to the link which points to it. That means in order to figure out whether or not the links in the list will actually be freed, I have to recurse back through all the references in my head in order to figure out whether or not memory used by each link in the list will be freed when I forget about the pointer to my path.
Comparatively, if things worked in a normal manner it would be qute simple to know what is freed, because I have to EXPLICITLY free it, or I KNOW it hasn't been freed.
Ie, when I free a path, I have a list of points in that path. I need to first free all the points in the list, and then free the list. Then I'm done.
I don't need to think about the fact that the list points back to the points and then go into the bowels of Max's source code and the docs to find out that Types have a special delete method, and when the garbage collector frees it, the delete method is called, and that this delete method in Max's source calls the remove method for all the links in the list, and the remove method for those links set the link's value to Null, which is actually the pointer to the object that it was pointing to, and that by setting this to Null the reference is removed, and that this is fortunate, because if Mark had simply assumed that when you lose the list reference that all references to the links in the list would also be lost, and that said pointer would automatically be set to Null when the link is freed, then we'd have a problem, because now the link would point back to the point, and the point would point back to the link, and neither would ever get freed.
Because of this Mark's elegant solution is less elegant because it becomes dangerous to assume that any pointer will automatically be set to Null when the object is freed, because circular references like this will end up causing memory leaks.
So in effect, Mark has simply replaced Delete Pointer with Pointer = Null. If we do not do Pointer = Null whenever we want something to be freed, just before it would be freedd normally if not for circular linkages, then because of the circular linkage issue, we will have to go through insanely complicated leaps of logic as outlined above to figure out whether stuff will be freed or not.
Take this comment for example, which I need to have in my code to remind me that stuff will actually get freed when I free a path in my sprite system:
' Freeing the path will cause the app to lose the reference to the point list, which will cause the point list to be freed, which sets the value for each ' link to Null, which means that nothing will be pointing at the points that were in the list, so they will be freed, which in turn will allow the links ' in the list which the points were pointing back to to be freed.
See what I mean?
Each point in my pointlist points back to the link which points to it. That means in order to figure out whether or not the links in the list will actually be freed, I have to recurse back through all the references in my head in order to figure out whether or not memory used by each link in the list will be freed when I forget about the pointer to my path.
Comparatively, if things worked in a normal manner it would be qute simple to know what is freed, because I have to EXPLICITLY free it, or I KNOW it hasn't been freed.
Ie, when I free a path, I have a list of points in that path. I need to first free all the points in the list, and then free the list. Then I'm done.
I don't need to think about the fact that the list points back to the points and then go into the bowels of Max's source code and the docs to find out that Types have a special delete method, and when the garbage collector frees it, the delete method is called, and that this delete method in Max's source calls the remove method for all the links in the list, and the remove method for those links set the link's value to Null, which is actually the pointer to the object that it was pointing to, and that by setting this to Null the reference is removed, and that this is fortunate, because if Mark had simply assumed that when you lose the list reference that all references to the links in the list would also be lost, and that said pointer would automatically be set to Null when the link is freed, then we'd have a problem, because now the link would point back to the point, and the point would point back to the link, and neither would ever get freed.
Because of this Mark's elegant solution is less elegant because it becomes dangerous to assume that any pointer will automatically be set to Null when the object is freed, because circular references like this will end up causing memory leaks.
So in effect, Mark has simply replaced Delete Pointer with Pointer = Null. If we do not do Pointer = Null whenever we want something to be freed, just before it would be freedd normally if not for circular linkages, then because of the circular linkage issue, we will have to go through insanely complicated leaps of logic as outlined above to figure out whether stuff will be freed or not.