Interestingly enough Ive just read an article about this on MSDN, and the new managed C++ and the other .net versions now work on the BMax model (sort of), that is the code manager (net) looks ahead and decides if the object is to be used again, then it desides to call the the ~ destructor. It actualy went so far as to tell you when to set the object to NULL
Well, just as long as you can still "delete" objects on demand, it's fine with me. But if .net C++ removes the "delete" keyword, then I don't think I'll be using it.
Garbage collection is fine as a add-on to prevent programmer errors (memory leaks), and also has it's use for resource management. But I think that the ability to "delete" objects on demand should always be an option for the programmer.
For example, which do you prefer - this:
resolutionNode.Free() resolutionNode = Null Settings.Resolution = Null 'Let's hope that the node wasn't referenced anywhere else, or it won't get deleted and we'll have a serious bug
Or this:
Delete resultionNode
You don't set all references to null, you simply remove it from your collection
Isn't "removing it from your collection" synonymous with "set all references to it to null"?
and wait for it to go out of scope
That may be just fine for most windows applications, but in real-time programming you need things to happen exactly when and how you want. No "waiting for the garbage collection to kick in".
And yes, I definitely prefer a language that actively prevents rogue pointer bugs.
First of all, bugs will happen in every language. I'm all for bug detection (like memory leak logs), but I do not like it when a language silently "fixes" your bugs - this can lead to extremely unpredictable behavior.
Garbage collection is fine as a add-on to a standard program as a "memory leak band-aid", but it takes a programmer to actually "heal" the wound.