3 ms·

Side note... 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 ac

Side note... 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.

bexsella 5y ago
I think even the most hardcore of RAII adherents would say that RAII is a dreadful name for it.
kjeetgill 5y ago
> just sounds like it describes object constructors. 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).
Diggsey 5y ago
It comes from C++ where memory being "initialized" to a particular type has a very specific meaning in the language: when a constructor is called on a memory location, it becomes intialized to the type of that constructor, and the reverse when the destructor is called. "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.
kragen 5y ago
"RAII" describes what you have to do to make resource releasing work correctly in C++ when there are exceptions all over the place. If you first acquire a resource and then later initialize an object with it, or assign it to an object, there's a time window when the resource has been acquired but is not yet owned by the object, during which an exception will cause it to leak. If, for example, the object's operator= raises an exception before safely storing the resource, you lose. 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.
- pjmlp 5y ago
  RAII was invented before C++ considered exceptions. 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.
  - kragen 5y ago
    I think you're using the term "RAII" in a much looser sense, and we didn't call it that at the time (though I don't have a convenient way to demonstrate this now that Google Groups has nerfed their search). C++ code from that period (and Google C++ code to this day) violates RAII regularly by acquiring resources in non-initialization contexts. 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; Without RAII, without exceptions, with destructor cleanup, perfectly OK: int fd = open(fname, O_RDONLY); if (fd < 0) return FAIL; File file = fd; ... return OK; Without RAII, with exceptions, terrible buggy dangerous code: int fd = open(fname, O_RDONLY); if (fd < 0) return FAIL; File file = fd; ... return OK; Note that this is exactly the same as the previous "perfectly OK" example! 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; Correct version: File file(fname, O_RDONLY); if (!file.ok) return FAIL; ... return OK; With RAII, with exceptions, perfectly OK: File file(fname, O_RDONLY); ... return OK; Note that this is exactly the same as the "terrible buggy dangerous code" above. The difference is only that now the File constructor signals failure by throwing an exception instead of setting a flag. 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.)
FpUser 5y ago
>"Does anyone else feel like RAII is poorly named" 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.
- kibwen 5y ago
  Forget the acronyms, I'd just call it "scoped destruction". :)
- nazka 5y ago
  I like your version thought, it emphases both sides directly. You got a resource? Well you have to deal about how to release it too. Maybe just a general term like: Resource Acquisition And Release? Let's be RAAD about being sure we release all resources :)
MereInterest 5y ago
C++ isn't exactly known for having good acronyms. CRTP ("curiously recursive template pattern") at least tells you that it has to do with templates. SFINAE ("substitution failure is not an error") tells you nothing about the context, nor how it would be used, despite being fundamental to metaprogramming in C++.

bexsella 5y ago

I think even the most hardcore of RAII adherents would say that RAII is a dreadful name for it.

kjeetgill 5y ago

> just sounds like it describes object constructors. 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).

Diggsey 5y ago

It comes from C++ where memory being "initialized" to a particular type has a very specific meaning in the language: when a constructor is called on a memory location, it becomes intialized to the type of that constructor, and the reverse when the destructor is called. "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.

kragen 5y ago

"RAII" describes what you have to do to make resource releasing work correctly in C++ when there are exceptions all over the place. If you first acquire a resource and then later initialize an object with it, or assign it to an object, there's a time window when the resource has been acquired but is not yet owned by the object, during which an exception will cause it to leak. If, for example, the object's operator= raises an exception before safely storing the resource, you lose. 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.

pjmlp 5y ago
RAII was invented before C++ considered exceptions. 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.
- kragen 5y ago
  I think you're using the term "RAII" in a much looser sense, and we didn't call it that at the time (though I don't have a convenient way to demonstrate this now that Google Groups has nerfed their search). C++ code from that period (and Google C++ code to this day) violates RAII regularly by acquiring resources in non-initialization contexts. 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; Without RAII, without exceptions, with destructor cleanup, perfectly OK: int fd = open(fname, O_RDONLY); if (fd < 0) return FAIL; File file = fd; ... return OK; Without RAII, with exceptions, terrible buggy dangerous code: int fd = open(fname, O_RDONLY); if (fd < 0) return FAIL; File file = fd; ... return OK; Note that this is exactly the same as the previous "perfectly OK" example! 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; Correct version: File file(fname, O_RDONLY); if (!file.ok) return FAIL; ... return OK; With RAII, with exceptions, perfectly OK: File file(fname, O_RDONLY); ... return OK; Note that this is exactly the same as the "terrible buggy dangerous code" above. The difference is only that now the File constructor signals failure by throwing an exception instead of setting a flag. 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.)

FpUser 5y ago

>"Does anyone else feel like RAII is poorly named" 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.

kibwen 5y ago
Forget the acronyms, I'd just call it "scoped destruction". :)
nazka 5y ago
I like your version thought, it emphases both sides directly. You got a resource? Well you have to deal about how to release it too. Maybe just a general term like: Resource Acquisition And Release? Let's be RAAD about being sure we release all resources :)

MereInterest 5y ago

C++ isn't exactly known for having good acronyms. CRTP ("curiously recursive template pattern") at least tells you that it has to do with templates. SFINAE ("substitution failure is not an error") tells you nothing about the context, nor how it would be used, despite being fundamental to metaprogramming in C++.