Because COM uses reference-counting garbage collection COM objects can be used as RAII objects (indeed I said you could use VB6 classes for RAII and internally all VB6 classes “look” like COM even if they aren’t exposed as such).

A good example is the classes provided by calls to the FileSystemObject. File and TextStream objects will call Close() when they are destroyed if necessary, so while RAII is not the primary advantage they give over other mechanisms (they are simpler than some alternatives, and the only out-of-the-box way to deal with files in script) they have all the advantages of RAII.

Of course a pointer to a COM object is in itself a resource that must be carefully managed. If you are using a scripting language or VB6 then the calls to AddRef() and Release() are managed for you, but in C++ they must be carefully matched. The CComPtr and CComQIPtr templates provided by ATL use RAII techniques to take much of this burden off the programmer, as is the _com_ptr_t templates provided by VC++ if you #import without the no_smart_pointers attribute.

The Standard Template Library makes use of the RAII technique in many places. The file stream templates (std::basic_ifstream, std::basic_ofstream and std::basic_fstream) for example will close the file stream on destruction if close() hasn’t yet been called.

RAII is also directly supported by the std::auto_ptr template. Its destructor will call delete on the pointer if it “owns it” (it will for instance stop “owning” a pointer if it is assigned to another std::auto_ptr). Hence it uses RAII to prevent memory leaks.

The runtime performance costs of this technique obviously depend on quite a few factors.

In C++ the cost is typically nil, or an actual improvement in runtime performance over alternative techiques. As these classes have inline non-virtual constructors and destructors the code produced by an optimising compiler should be pretty much identifcal to that of the equivalent using explicit resource acquisition and release. The class will also typically use no memory, or no more than would have been necessary through other methods.

In cases where the code executed between acquisition and release is more complicated, and in particular where there are a wide variety of possible exceptions that could be thrown, this technique is typically more efficient than alternative techniques which involve either checking state or catching exceptions to rethrow them after perfoming the necessary cleanup.

In cases where the acquisition and/or release is itself complicated the runtime complexity generally increases at the same or a slower rate with RAII than with alternative techniques, and at this point efficiency itself is a good reason to consider RAII. It’s worth noting that even if a virtual destructor is needed for an RAII class it is generally possible for the virtual selection mechanism to be performed at compile-time rather than through the vector table (or whatever implementation of virtual functions is used) — since the compiler knows the exact type of the object it does not need to use the virtual mechanism at run-time.

In VB6 the cost is typically greater. All VB6 classes are internally COM classes. As such they all have implementations of IUnknown (and IDispatch), a reference count, a degree of thread-safety, are created on the heap, and their creation and destruction is controlled by virtual calls to AddRef() and Release().

It appears from experimentation that these features are not optimised away by the compiler, certainly not the implementation of IUnknown.

This means that in designing VB6 programs we cannot use RAII quite as freely as in C++. The benefits far outweigh the costs in cases where analysis of the possible conditions is daunting and liable to change, in less complicated cases the decision is more difficult to make.

In all languages the effects of RAII on the readability of code will depend largely on how clear the purpose and semantics of the RAII class is. As I’ll go into in more detail later, an RAII class should be considered a design tool and its use a notational benefit to the function in which it is used.

Because RAII is better known in C++ than VB a class that exists primarily for RAII purposes may seem a bit “foreign” to a VB coder. Alternatively VB coders are generally used to classes cleaning up after themselves completely and will expect RAII behaviour when a class is used to give access to a resource. C++ coders will not necessarily expect this, though at all but the lowest levels of abstraction any class that does not exhibit such behaviour is poorly designed.

There is often a slight increase in the complexity of “stepping through” code in a debugger if you step into the class’s constructor and destructor. However once the class is tested, trusted, and well known these can be stepped over and the task of stepping through code is simplified.

There is generally a run-time performance hit when debugging even in C++. But worries about run-time performance of a debug build are obviously misguided.

The important features of pure RAII classes like std:auto_ptr are efficiency, transparency, and reliability.

Efficiency

Typically these classes should have little or no run-time disadvantages compared to alternative methods. They typically are “free-standing”, without any public bases, have no virtual functions, and have only inline functions. Their internal representation is generally the absolute minimum for the tasks the perform, often nothing more than one variable which contains the type used by the lower-level functionality wrapped (a file handle, window handle, pointer to memory, etc.) Often their representation is a reference to an object created by external operations. In this case the reference can often be optimised away.

Transparency

Use of the class should generally be equivalent to, or a more user-friendly version of, use of the underlying resource. Use of an std::auto_ptr through * or -> is identical to use of a pointer. The ATL win class provides all the Windows API functions, but as member of the class. Often it is appropriate to allow these types to be cast to the types of their underlying representation.

Reliability

The whole purpose of using a pure RAII class is to gain reliable control over some potentially dangerous aspect of the underlying resources behaviour. Obviously this control must be provided. It is important that documentation state clearly which features are or are not made safer. For example a user might expect it to become safe to dereference a null std::auto_ptr were it not made clear that there is no extra protection offered in this case (of course an auto_ptr like class that does provide such protection can be easily created if appropriate).

With higher level classes RAII is generally taken for granted by users. Certainly any class that is part of the public interface of a component or library that is not specifically geared towards low-level use should clean up after itself correctly or its design is clearly flawed.

At this level of abstraction the real question is to make sure that the RAII behaviour is reliable and error-free. Often using lower-level RAII classes as part of the internal representation is a good way to do this.

The design of any class should consider the state that exists before and after creation, before and after destruction, and invariants that will exist before and after any function is called on a fully constructed object. RAII helps this design task.

With classes that are not easily labelled “low level” or “high level” design becomes somewhat less clear-cut. Not only is RAII not a given with low level classes, but it is often inappropriate at that level (when a class deals with a resource, but does not “own” it). You should have a good idea of exactly what level of abstraction a class operates at, and should communicate this clearly to the class’s user. A class which doesn’t seem to fit well at a single level of abstraction is almost invariably a poorly-designed class.

RAII classes can be particularly useful when the scope which governs their lifetime is another class. Where this comes into its own is in cases where constructors or destructors can throw exceptions.

In C++ the order of construction is that first the base, and then all member objects are constructed in the order of their declaration. Then the constructor’s body (if any) is executed. This is conceptually recursive, with the same process happening to any member objects of member objects, though with inline constructors this recursion doesn’t really involve the overhead of a function call.

The order of destruction is the opposite, first the body of the destructor is called, then the destructors for member objects, then the destructor of the base.

This means that if a member object with RAII semantics has been created and an exception happens before the constructor has completed then its destructor will be called as part of the stack unwinding. Hence an object which controls multiple resources can guarnatee their cleanup even if it isn’t fully constructed by using member RAII objects.

Further, if there is a dependency between the acquisition and release of two or more resources they generally tend to be nested, that is the first resource acquired must be the last released. This naturally matches the order of construction and destruction of C++ classes.

One thing to be careful of is the danger of throwing exceptions in destructors. This is generally true whether a class uses RAII or not. If a destructor is being executed during the process of an exception being thrown (most often because of stack-unwinding) and it throws an exception then, as always if an exception is thrown while another exception is currently being thrown, terminate() will be called.

Some people say that you should never allow an exception to escape a destructor. This isn’t strictly true, though it is a good principle to follow when possible. Since an RAII class is designed with exception safety in mind, it is wise to avoid giving them destructors that can throw exceptions. However the very nature of their destructors means it is often important that they can throw exceptions. Calling uncaught_exception() allows a destructor to check if it can throw an exception without calling terminate(). However you may decide that calling terminate() is appopriate, particularly for small programs that can signal failure to complete through their return code.

In VB there isn’t the same guarantee about order of destruction of member objects, but the same general principle applies.

We’ve seen how RAII can help the design of individual classes and functions, and what is involved in the design of RAII classes themselves. When looking at the wider scope of a component, library or application RAII stops being about exception-handling mechanisms, and becomes part of the overall exception-management strategy.

RAII answers a lot of cases where some developers avoid conventional exception mechanisms in favour of other techniques (such as returning values indicating failure, or setting global error number variables) with the myriad problems they bring.

RAII adds resiliance to code that cannot know what exceptions may be thrown, in particular code that calls virtual functions, or code that calls functions which depend upon template arguments.

RAII makes it easier to allow exceptions which are the “concern” of other components to pass through them from the component that threw the exception to the component that will catch it. This helps you to guarantee good exception-safe behaviour without knowledge of the exceptional circumstances that will be involved.