Benefit of Garbage Collection?
BlitzMax Forums/BlitzMax Programming/Benefit of Garbage Collection?
| ||
| Being a long time blitz3d & blitzplus user, and only ever dabbling with the blitzmaxdemo, and having read posts such as http://blitzbasic.com/Community/posts.php?topic=91478 it makes me wonder why anyone would want to use garbage collection. Maybe I'm thinking far too procedurally but in the other blitz languages as long as you always free what you create, whether they be banks, sounds, images, textures, etc you don't have to worry about memory leaks. And with well designed code not only should you never have to worry about memory leaks but you never have to worry about referencing objects that no longer exist... Does garbage collection encourage lazy programming? Also, I must admit I like that 'handles' in blitz+/blitzbasic/blitz3d were just 4 byte signed integers. Just my own thoughts...admittedly I've not done much object orientated programming so would like to hear what the benefits of garbage collection are compared to programming in such a way that memory allocation/deallocation is taken care of by the programmer. |
| ||
| It's just a time saver to let it do it automatically for you, and also then to ensure that there aren't any that you forgot to deallocate. |
| ||
| like ImaginaryHuman said, it's a time saver. But it is a HUGE time saver in any sizable project. Also memory leaks tend to happen because you forget to release something even if you dereference it, with a garbage collector that's a non issue, so it actually tends to prevent leaks... However it takes processing time, and it may not be perfect, so there are always trade offs. iphone for example has no garbage collector so you must handle everything yourself (HUGE hassle) where as mac OS does have a garbage collector so you can essentially write the same code only skipping all the allocation controls. I personally prefer manual collection despite the hassle because when things go wrong it's my fault which means I can fix it. It also means that you can eek the last drops of performance out where it counts. I also have a bad habit of running into GC problems (see other recent threads...) |
| ||
| For all its flaws, when you've tasted the sweet goodness of the garbage collector, there is no going back. |
| ||
| The topic you link to is misleading as it wasn't a memory leak, it just wasn't getting enough time to free the last object. Once the program ends all resources are freed anyway. |
| ||
| Garbage collection adds ambiguity to the code execution, which is always bad. C++ style references are okay, but GC sucks. But it is a HUGE time saver in any sizable project. I end up writing more code to make sure all references to the object I want to get rid of are set to null, then finding places where the memory builds up and a GC collect call are needed, because automatic GC mode causes even more problems. |
| ||
| Why is Nulling references so much harder than deleting an object manually? |
| ||
| with GC... if you want to get rid of something e.g. a mesh you have to remember all the lists it is on, if you 'free' something or as in Blitz3D (freemesh) the program will crash when a reference to a freed object is found so you can find out which lists the mesh is on instead of having to remember. If a way could be found so that the program doesnt crash when a freed object is found and the object reference is merely removed from the list or 'nulled' in an array that would be very nice.Better than garbage collection. |
| ||
| So in both situations you have to find all the references and do something about them. Trying to find what refers to your object by simply trying to crash the program hardly seems a good way to go about it. There is nothing to stop you placing some kind of active/alive flag inside your object, and causing an exception if an object that is marked as inactive has one of its methods called. You can put the check in ?debug ?. Then you can find hidden references in the same haphazard fashion! Most of the references will come from lists, no? Well you can create a "linkbank" or link manager object each object has, that maintains a list of all links to the object that can be removed when the object is no longer required. There are plenty of solutions. At the end of the day, neither way poses a problem so long as you design your program thoroughly. You should know where your objects will be referenced. |
| ||
| You should know where your objects will be referenced. true but I dont like to plan :) There is nothing to stop you placing some kind of active/alive flag inside your object, and causing an exception if an object that is marked as inactive has one of its methods called. You can put the check in ?debug ?. Then you can find hidden references in the same haphazard fashion! true good point Most of the references will come from lists, no? Well you can create a "linkbank" or link manager object each object has, that maintains a list of all links to the object that can be removed when the object is no longer required. There are plenty of solutions. Probly be easier to keep track of stuff manually.:) |
   |