Does anyone else feel like RAII is poorly named? It seems to me that the largest benefits of RAII that people talk about aren't about resource acquisition or initialization, but releasing the resource. Taking the phrase "Resource Acquisition Is Initialization" at face value just sounds like it describes object constructors.
"Resource Acquisition Is Initialization". ie. You cannot separate the acquisition of the resource from the initialization of the type (and by implication, you cannot separate the release of the resource from the destruction of the type).
The language already required that initialization/deinitialization is correctly paired for all programs, so RAII was a way to take that guarantee and use it to manage resources as well. And since for local variables it is the compiler itself that upholds the guarantee, the compiler can also ensure resources are acquired/freed correctly.
Without that specific context, the name is poor, but C++ popularized the concept and its name, and once a specific technical name for something exists it's a good idea to continue to use it so as to avoid ambiguity when communicating, even after the originating context is lost.
Alternative names like "constructor acquires, destructor releases" might be better, but I think "RAII" was sort of devised as a slogan to shout at people so they would fix their code.
Back in MS-DOS/Windows 3.x, and Mac OS, CFront/UNIX days, RAII was used for file handles, network connections, other sort of OS handles, and naturally data structures like dynamic strings and arrays.
When exceptions came into scene, RAII was already established as pattern.
RAII without exceptions is pretty inconvenient: acquiring resources can almost always fail (the only exception I can think of is locks) and so you need some kind of return value, which is precisely what you don't have in a constructor. So you need a flag value in the initialized object which you later have to check, which means that all your resourcy objects are "nullable", in the sense that the type system can't guarantee you that they're in a meaningful state, and you need a dynamic check.
Maybe you mean that people commonly used destructors for cleanup before C++ had exceptions, and I certainly agree with that. But using destructors for cleanup is not the same thing as RAII.
Without RAII, without exceptions, without destructor cleanup, perfectly OK:
int fd = open(fname, O_RDONLY);
if (fd < 0) return FAIL;
...
close(fd);
return OK;
int fd = open(fname, O_RDONLY);
if (fd < 0) return FAIL;
File file = fd;
...
return OK;
int fd = open(fname, O_RDONLY);
if (fd < 0) return FAIL;
File file = fd;
...
return OK;
You can try to fix this up with catch(...) { close(fd); throw; } but the correctness of such convolutions depends intimately on the precise contours of how exceptions can happen, if at all, in the File constructor.
With RAII, without exceptions, terrible buggy dangerous code:
File file(fname, O_RDONLY);
...
return OK;
File file(fname, O_RDONLY);
if (!file.ok) return FAIL;
...
return OK;
File file(fname, O_RDONLY);
...
return OK;
This is also the most efficient of all the versions on the happy path because it doesn't waste memory on success flags or conditional jumps (in this function and in its caller) on checking them. It's also the most concise and, arguably, the least error-prone. (Google policy disagrees.)
I think I've said this verbatim, so you have my vote. I'm curious what other names people might give it.
Wikipedia gives:
> Other names for this idiom include Constructor Acquires, Destructor Releases (CADRe) and one particular style of use is called Scope-based Resource Management (SBRM).
Me, me, me
It should be RAIR - Resource Acquisition Is Release.
P.S. Never mind. As somebody else mentioned SBRM - Scope Based Resource Management -s the best I think.