C++ Programming/RAII

Resource Acquisition Is Initialization (RAII)
The RAII technique is often used for controlling thread locks in multi-threaded applications. Another typical example of RAII is file operations, e.g. the C++ standard library's file-streams. An input file stream is opened in the object's constructor, and it is closed upon destruction of the object. Since C++ allows objects to be allocated on the stack, C++'s scoping mechanism can be used to control file access.

With RAII we can use, for instance, Class destructors to guarantee clean up, similar to the finally keyword in other languages. Doing this automates the task and so avoids errors but gives the freedom not to use it.

RAII is also used (as shown in the example below) to ensure exception safety. RAII makes it possible to avoid resource leaks without extensive use of /  blocks and is widely used in the software industry.

The ownership of dynamically allocated memory (memory allocated with new) can be controlled with RAII. For this purpose, the C++ Standard Library defines auto ptr. Furthermore, lifetime of shared objects can be managed by a smart pointer with shared-ownership semantics such as  defined in C++ by the Boost library or policy based   from Loki library.

The following RAII class is a lightweight wrapper to the C standard library file system calls.

This RAII class can be used as follows :

Without using RAII, each function using an output log would have to manage the file explicitly. For example, an equivalent implementation without using RAII is this:

The implementation of  and   becomes more complex if   and   could potentially throw exceptions;   would be unaffected, however.

The essence of the RAII idiom is that the class  encapsulates the management of any finite resource, like the   file handle. It guarantees that the resource will properly be disposed of at function exit. Furthermore,  instances guarantee that a valid log file is available (by throwing an exception if the file could not be opened).

There's also a big problem in the presence of exceptions: in, if more than one resource were allocated, but an exception was to be thrown between their allocations, there's no general way to know which resources need to be released in the final   block - and releasing a not-allocated resource is usually a bad thing. RAII takes care of this problem; the automatic variables are destructed in the reverse order of their construction, and an object is only destructed if it was fully constructed (no exception was thrown inside its constructor). So  can never be as safe as   without special coding for each situation, such as checking for invalid default values or nesting try-catch blocks. Indeed, it should be noted that  contained resource bugs in previous versions of this article.

This frees  from explicitly managing the resource as would otherwise be required. When several functions use, this simplifies and reduces overall code size and helps ensure program correctness.

resembles the idiom used for resource management in non-RAII languages such as Java. While Java's try-finally blocks allow for the correct release of resources, the burden nonetheless falls on the programmer to ensure correct behavior, as each and every function using  may explicitly demand the destruction of the log file with a try-finally block.