6 ms·

Can someone explain RAII to me? In the way that it's commonly used, it seems like it really means "stack variables that go out of scope are deallocated", which

by nsmnsf 13y ago

Can someone explain RAII to me? In the way that it's commonly used, it seems like it really means "stack variables that go out of scope are deallocated", which seems kind of, well, duh? I don't really understand why it's treated like a big deal. (I mostly write C + Obj-C)

julian37 13y ago
Stack variables that go out of scope are deallocated, that's one of the points of RAII (an advantage over dynamic allocation, especially because scope is also terminated by exceptions.) But crucially, their destructor is called (and any destructors of their member variables, etc.) The destructor might perform cleanup work beyond freeing up memory. For example, std::istream will close the file handle when it goes out of scope, and boost::lock_guard will release the lock. RAII isn't rocket science, but there are some advantages over plain C where all cleanup has to be explicit and it's fairly easy to get resource deallocation wrong if you don't know what you're doing. And as the Wikipedia article says, RAII is vital in writing exception-safe code in C++ if you don't want to litter try/catch blocks all over your code. http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initial...
dllthomas 13y ago
RAII is "Resource Acquisition Is Initialization", and it means "tie the lifetime of a resource to the lifetime of an object" because we have ways of making sure objects are released when they are no longer wanted (of which stack allocation is the easiest, when it's applicable).
DerKommissar 13y ago
mutex.lock(); doStuff(); /*throws an exception, mutex is never unlocked*/ mutex.unlock(); ScopedLock lock(mutex); doStuff(); /*mutex unlocked by destructor in all cases*/ It guarantees that resources are freed no matter how the scope exits.
coherentpony 13y ago
https://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization https://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initia...
masklinn 13y ago
> it seems like it really means "stack variables that go out of scope are deallocated" And the destructor, if any, is called. That means you can bundle automatic cleanup action in the destructor, no need for goto: cleanup, @try/@finally or some other sort of "manual" cleanup, the cleanup is implicitly set up by, well, the setup. The ability itself is by no means unique to C++ (even amongst oldies, Smalltalk has BlockClosure#ensure: and Common Lisp has unwind-protect) but a surprising number of languages still don't have such a capability, and it's a pretty neat consequence of C++'s memory model.
- nsmnsf 13y ago
  > And the destructor, if any, is called Right, that's implied by a C++ object being deallocated. I understand how it works - it's just that it's really obvious if you know anything at all about how the stack works (and C++ destructors).
  - benched 13y ago
    The "non obvious" part that makes it RAII is simply that the stack variable in question owns another resource besides itself. The stack variable is being used to wrap something else, be it a chunk of memory, a file handle, one or more other dynamically allocated objects, etc. The key in RAII is that when the stack variable wrapper goes out of scope, the wrapped resource (which is in addition to the stack variable) is deallocated, freed, released, etc.
  - EpicEng 13y ago
    It's using automatic storage duration and destructors tow age dynamically allocated memory (or some other resource which require manual management.). So yeah, that's it.
  - masklinn 13y ago
    > it's just that it's really obvious if you know anything at all about how the stack works (and C++ destructors). Which does not change it being an elegant solution to the problem of resource scoping does it? Also the semantics of C++ destructor (and their relation to stack deallocation) had to be defined to get RAII, and it was, back in the very early 80s when the idea of resource scoping was not exactly well known.
detrino 13y ago
To better understand the importance of RAII, you might consider what some other languages offer to solve similar problems. Consider a C example: int f() { int ret = -1; handle * a = acquire_handle(0); if (a == NULL) goto fail1; handle * b = acquire_handle(1); if (b == NULL) goto fail2; handle * c = acquire_handle(2); if (c == NULL) goto fail3; // use a, b, c ret = 0; release_handle(c); fail3: release_handle(b); fail2: release_handle(a); fail1: return ret; } Consider a C# example: void f() { using (handle a = new handle(0)) using (handle b = new handle(1)) using (handle c = new handle(2)) { // use a, b, c } } Now a C++ example using RAII: void f() { handle a{0}; handle b{1}; handle c{2}; // use a, b, c } These examples are mostly equivalent (Although the C#/C++ assume exceptions instead of error codes). The C#/C++ examples are far more structured and less error prone than the C example. The advantage of C++'s RAII over C#'s using statement is that cleanup is tied to the object rather than a statement. This means that RAII is both composable and non-leaky as an abstraction. You cannot forget to destruct an object in C++, and you don't have to care that its destructor frees resources. When you have an IDisposable member in C# you must manually mark your class as IDisposable and then implement the Dispose method yourself. Clients must also be aware that your class is IDisposable in order to use it correctly.
- voidlogic 13y ago
  Go: func f() error { var a, b, c *handle var err error if a, err = acquireHandle(0); err != nil { return err } defer a.Close() if a, err = acquireHandle(1); err != nil { return err } defer b.Close() if a, err = acquireHandle(2); err != nil { return err } defer c.Close() //use a, b, c return nil }
  - detrino 13y ago
    Thanks for the example, seems like Go's solution is better than C but has the same problems as C#: non composable and leaky.
Nursie 13y ago
To my mind it's like stack objects - not only do you not have to worry about freeing them, the destructor gets called and so do subordinate destructors for memeber objects. It was a bit of a revelation when I did some 'real' c++ for the first time a couple of years back. In some ways it is just another of the myriad of implicit behaviours in C++ that make it hard to work with, though.
lutorm 13y ago
The crucial idea is that what's pointed to by those variables is also cleaned up. When a POD pointer goes out of scope, it doesn't help you that the pointer is deallocated, you need what's pointed to to be deallocated. Beyond pointers, it applies to many things that have a "C-style" API. Without RAII, anything that needs to be explicitly cleaned up needs to be monitored. For example, if you declare a pthread mutex, it doesn't help you that the mutex variable itself goes out of scope, because it's just a pointer and that will not clean up the actual mutex. And as people have said, without RAII it's impossible to write exception-safe code.
- dllthomas 13y ago
  "And as people have said, without RAII it's impossible to write exception-safe code." Assuming that's hyperbole, I agree with the sentiment. It's possible to write exception safe code with try & catch - it's just almost as ugly as checking exit statuses and easier to miss something.
thought_alarm 13y ago
> "stack variables that go out of scope are deallocated" That's all it is. But, it guarantees that a given piece of code (an object's destructor) is always executed when execution leaves the current scope, either through normal execution, by calling `return`, or by throwing an exception. In fact, RAII is the thing that allows exceptions to be remotely usable in C++; the lack of RAII in Obj-C is the reason why exceptions are not common in Obj-C. It's used for regular memory management, but it's also used for managing access to other resources, such as files, mutexes, etc. E.g., you can use it ensure that a file handle is automatically closed when you leave scope.

by nsmnsf 13y ago

julian37 13y ago

Stack variables that go out of scope are deallocated, that's one of the points of RAII (an advantage over dynamic allocation, especially because scope is also terminated by exceptions.) But crucially, their destructor is called (and any destructors of their member variables, etc.) The destructor might perform cleanup work beyond freeing up memory. For example, std::istream will close the file handle when it goes out of scope, and boost::lock_guard will release the lock. RAII isn't rocket science, but there are some advantages over plain C where all cleanup has to be explicit and it's fairly easy to get resource deallocation wrong if you don't know what you're doing. And as the Wikipedia article says, RAII is vital in writing exception-safe code in C++ if you don't want to litter try/catch blocks all over your code. http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initial...

dllthomas 13y ago

RAII is "Resource Acquisition Is Initialization", and it means "tie the lifetime of a resource to the lifetime of an object" because we have ways of making sure objects are released when they are no longer wanted (of which stack allocation is the easiest, when it's applicable).

DerKommissar 13y ago

mutex.lock(); doStuff(); /*throws an exception, mutex is never unlocked*/ mutex.unlock(); ScopedLock lock(mutex); doStuff(); /*mutex unlocked by destructor in all cases*/ It guarantees that resources are freed no matter how the scope exits.

coherentpony 13y ago

https://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization https://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initia...

masklinn 13y ago

> it seems like it really means "stack variables that go out of scope are deallocated" And the destructor, if any, is called. That means you can bundle automatic cleanup action in the destructor, no need for goto: cleanup, @try/@finally or some other sort of "manual" cleanup, the cleanup is implicitly set up by, well, the setup. The ability itself is by no means unique to C++ (even amongst oldies, Smalltalk has BlockClosure#ensure: and Common Lisp has unwind-protect) but a surprising number of languages still don't have such a capability, and it's a pretty neat consequence of C++'s memory model.

nsmnsf 13y ago
> And the destructor, if any, is called Right, that's implied by a C++ object being deallocated. I understand how it works - it's just that it's really obvious if you know anything at all about how the stack works (and C++ destructors).
- benched 13y ago
  The "non obvious" part that makes it RAII is simply that the stack variable in question owns another resource besides itself. The stack variable is being used to wrap something else, be it a chunk of memory, a file handle, one or more other dynamically allocated objects, etc. The key in RAII is that when the stack variable wrapper goes out of scope, the wrapped resource (which is in addition to the stack variable) is deallocated, freed, released, etc.
- EpicEng 13y ago
  It's using automatic storage duration and destructors tow age dynamically allocated memory (or some other resource which require manual management.). So yeah, that's it.
- masklinn 13y ago
  > it's just that it's really obvious if you know anything at all about how the stack works (and C++ destructors). Which does not change it being an elegant solution to the problem of resource scoping does it? Also the semantics of C++ destructor (and their relation to stack deallocation) had to be defined to get RAII, and it was, back in the very early 80s when the idea of resource scoping was not exactly well known.

detrino 13y ago

To better understand the importance of RAII, you might consider what some other languages offer to solve similar problems. Consider a C example: int f() { int ret = -1; handle * a = acquire_handle(0); if (a == NULL) goto fail1; handle * b = acquire_handle(1); if (b == NULL) goto fail2; handle * c = acquire_handle(2); if (c == NULL) goto fail3; // use a, b, c ret = 0; release_handle(c); fail3: release_handle(b); fail2: release_handle(a); fail1: return ret; } Consider a C# example: void f() { using (handle a = new handle(0)) using (handle b = new handle(1)) using (handle c = new handle(2)) { // use a, b, c } } Now a C++ example using RAII: void f() { handle a{0}; handle b{1}; handle c{2}; // use a, b, c } These examples are mostly equivalent (Although the C#/C++ assume exceptions instead of error codes). The C#/C++ examples are far more structured and less error prone than the C example. The advantage of C++'s RAII over C#'s using statement is that cleanup is tied to the object rather than a statement. This means that RAII is both composable and non-leaky as an abstraction. You cannot forget to destruct an object in C++, and you don't have to care that its destructor frees resources. When you have an IDisposable member in C# you must manually mark your class as IDisposable and then implement the Dispose method yourself. Clients must also be aware that your class is IDisposable in order to use it correctly.

voidlogic 13y ago
Go: func f() error { var a, b, c *handle var err error if a, err = acquireHandle(0); err != nil { return err } defer a.Close() if a, err = acquireHandle(1); err != nil { return err } defer b.Close() if a, err = acquireHandle(2); err != nil { return err } defer c.Close() //use a, b, c return nil }
- detrino 13y ago
  Thanks for the example, seems like Go's solution is better than C but has the same problems as C#: non composable and leaky.

Nursie 13y ago

To my mind it's like stack objects - not only do you not have to worry about freeing them, the destructor gets called and so do subordinate destructors for memeber objects. It was a bit of a revelation when I did some 'real' c++ for the first time a couple of years back. In some ways it is just another of the myriad of implicit behaviours in C++ that make it hard to work with, though.

lutorm 13y ago

The crucial idea is that what's pointed to by those variables is also cleaned up. When a POD pointer goes out of scope, it doesn't help you that the pointer is deallocated, you need what's pointed to to be deallocated. Beyond pointers, it applies to many things that have a "C-style" API. Without RAII, anything that needs to be explicitly cleaned up needs to be monitored. For example, if you declare a pthread mutex, it doesn't help you that the mutex variable itself goes out of scope, because it's just a pointer and that will not clean up the actual mutex. And as people have said, without RAII it's impossible to write exception-safe code.

dllthomas 13y ago
"And as people have said, without RAII it's impossible to write exception-safe code." Assuming that's hyperbole, I agree with the sentiment. It's possible to write exception safe code with try & catch - it's just almost as ugly as checking exit statuses and easier to miss something.

thought_alarm 13y ago

> "stack variables that go out of scope are deallocated" That's all it is. But, it guarantees that a given piece of code (an object's destructor) is always executed when execution leaves the current scope, either through normal execution, by calling `return`, or by throwing an exception. In fact, RAII is the thing that allows exceptions to be remotely usable in C++; the lack of RAII in Obj-C is the reason why exceptions are not common in Obj-C. It's used for regular memory management, but it's also used for managing access to other resources, such as files, mutexes, etc. E.g., you can use it ensure that a file handle is automatically closed when you leave scope.