The problems start when you need to manage resources other than memory.

Examples of things that require explicit clean up: -> Files -> Sockets -> Transactions

The C++ resource model can be applied to all resources, not just memory.

Garbage collection only "solves" memory management for you - often that's the least important resource that your program is managing.

> often that's the least important resource that your program is managing

I think you're right but wrong here : it may be the least important in a technical sense, but the sheer amount of developer productivity lost in manual memory management is very expensive (for both the mental resources of the programmer and the firm), and this makes automated memory management a key positive.

Honestly, my eyes glazed over to avoid traumatic memories of C++ and Windows DOM internals as I read the article. I have a LIFE since I moved to Java.

True, however you have mechanisms like using, with, try, scope, defer that GC enabled languages offer.

C++ destructors benefit is that you don't forget to call such constructs.

Most (all?) of these cannot cope with trees of objects, plus that they leave the responsibility of destructing to the user of the object. So they are just as ugly as external locking. Problem is that very few people understand this, so they implement "using" and feel content. I would give an arm and a leg for RAII on the JVM.

> Most (all?) of these cannot cope with trees of objects

You can if all "destructors" take care of also closing the internal resources, thus initiating a cascade process of the object owned by them.

But you're right, this leaves the responsibility in the user's side.

> I would give an arm and a leg for RAII on the JVM.

At least they finally added the "using" concept.

In a few more versions maybe they get to add values.

Or in other words, garbage collection only covers about 99.999% of all resource allocations/deallocations ;-)

Patient0 said "the most important resources", not "the most frequently allocated resources".

The most important resource is the one that we spend the most time managing and that is clearly memory.

You don't need RAII to manage non-memory resources. All you need are first class functions.

The function trick suffices to handle objects with stack-shaped lifetime (certainly a very common case), but it does not suffice when resources are associated with parts of a data structure. The strength of RAII is that it handles both of these cases with the same machinery.

Could you expand on this a bit? I'd be interested to see an example of what you mean.

it's a ubiquitous pattern in ruby. this blog post uses a file open/close lifecycle manager as an example: http://yehudakatz.com/2012/01/10/javascript-needs-blocks/

That's more about coroutines than first class functions, and it is RAII, using a wrapper methodd for the actor/dtor instead of defining a class.

it is not raii as i understand the term. there is no destructor involved in closing the file, there is just a function that opens the file, passes your code the handle, then closes it when you're done.

Doesn't this amount to the same thing ?

it accomplishes the same purpose, but the filehandle gets closed explicitly, not when it goes out of scope and its destructor gets called.

No, but it is sometimes necessary for them to allocate big files and access them in a particular fashion. Or use an append-only data structure for the file and compact it now and then.

Sometimes exact control is what you need. It is no use trying to stop any discussion on the subject.

Not all resources are memory.