I think we're getting just a tiny bit too nitpicky on the language (yes, I know, I helped start it
)
Stroustrup was the one who came up with the name, so I think it's best to let
him explain it in his own words.
It's resource management, pure and simple. C++ uses constructors and destructors and the scope mechanism to make sure things that are initialized are cleaned up, and things that aren't initialized aren't (i.e. constructor threw an exception - which is the only way to get an error out of a constructor and maintain class invariants).
If I allocate/open/acquire a resource, I must deallocate/close/release said resource when I'm done with it. By allocating/opening/acquiring said resource in the constructor and saying that object "owns" that resource, then the destructor naturally deallocates/closes/releases that resource in all cases - normal or exceptional.
Does it solve all resource management issues? No. You still need to figure out your ownership. Some objects own uniquely (unique_ptr) some share ownership (shared_ptr). Use the right one for the job. Sometimes closing/releasing a resource can cause an error, in which case you want to have an explicit close/release function on the object because you cannot throw from a destructor. But the destructor is still there as a safety net (and should have a try/catch that eats any exceptions should the release have a chance to throw)
The standard library pointers and containers
are RAII because they manage the lifetimes of their contents through new/delete/malloc/free in constructors and destructors. Just because they might be empty doesn't mean they don't implement RAII - just like how a null pointer is still a pointer.
TLDR: I know how to manage the lifetime of one object. But I will screw up the lifetime of ten thousand objects. Let the compiler handle that after I tell it how to manage the lifetime of a single one and my code will be much more stable, bug free, and more secure.