World Wide Tutorial

Introduction
Take the case of a resource any manipulated through the class Resource, whose goal is to represent this resource point of view of language and allow its handling in C + +. It could be a network connection, for example. Our class resource called Socket then certainly not Resource.

Now imagine that you had to control the number of instances of this class Resource. In our example with the Socket class, it might be to limit the number of network connections simultaneously open. You'll then with the constraint of having to count the number of instances of Resource who are still in use. At first glance, this seems childish. But as always, and even more in C + +, this is not because there are many ways to do all they are worth. Let us therefore to an early solution.

Classical approach
Under this article, I decided to centralize the operations of creating and controlling the number of instances of Resource within a specialized manager called ResourceManager.

This class ResourceManager tantamount to a de facto factory, and has a member function New () to instantiate or not a new resource, and to keep track if it is never the case. The aim is to know at any moment the number of instances in use, to limit their number. The maximum number of instances is provided as a parameter to the constructor ResourceManager.
ResourceManager.h
Resource class;
typedef Resource * ResourcePtr;

ResourceManager class
(
public:
     / / Sets the maximum number of Resource simultaneously
     ResourceManager (int MaxNbInstances);
    
     / / Returns a new Resource it's less than
     / / MaxNbInstances in use, NULL otherwise.
     New ResourcePtr ();
);

If this interface design public use of ResourceManager is one thing, implementing it is another. For a problem arises: how to know the number of bodies set (easy) and still in use (a little less easy)? In other words, how to be informed in ResourceManager an object allocated via New () has been destroyed?

One solution, common in procedural programming, is to provide a pair of New function, which was responsible for the destruction of forums:
ResourceManager.h
Resource class;
typedef Resource * ResourcePtr;

ResourceManager class
(
public:
     / / Sets the maximum number of Resource simultaneously
     ResourceManager (int MaxNbInstances);
    
     / / Returns a new Resource it's less than
     / / MaxNbInstances in use, NULL otherwise.
     New ResourcePtr ();

     / / Delete a Resource allocation with New ()
     void Delete (ResourcePtr);
    
private:
     / / Number of instances in use
     int NbInstances;
     / / Maximum number of bodies authorised
     const int MaxNbInstances;
);

ResourceManager.cpp
# include "ResourceManager.h"
# include "Resource.h"

ResourceManager: ResourceManager (int Max):
     NbInstances (0),
     MaxNbInstances (Max)
(
)

ResourcePtr ResourceManager: New ()
(
     if (NbInstances <MaxNbInstances)
     (
         ResourcePtr r = new Resource ();
         / / On increments NbInstances _après_ be allocated
         / / Resource successfully to allow our
         / / Manager in a coherent state if an exception
         / / Was closed during the creation of an object Resource
         + + this-> NbInstances;
         return r;
     )
     return 0; / / NULL
)

void ResourceManager: Delete (ResourcePtr Res)
(
     If (Res)
     (
         -- this-> NbInstances;
         delete Res;
     )
)

Like ResourceManager: New () is responsible for instantiate objects of type Resource, ResourceManager: Delete () is responsible for destroying them. One could consider entrusting more work to these functions, such as maintaining a list of instances allocated, but I preferred to keep things as simple as possible.

Note the order of operations within ResourceManager: New (): Resource object is first allocated, then the meter NbInstances is updated, and especially not the reverse. For if the allocation of New Resource were to fail (because of lack of memory for example) and that an exception was lifted (std:: bad_alloc), the object ResourceManager then be left in an incoherent state: an object Additional Resource be recorded as being used while it does not exist.

The problem with this approach
This concept of twin functions based on a principle of programming most holy: It is he who has allocated an object that would destroy it. ResourceManager and is responsible for the creation but also the destruction of objects Resource through its torque functions New members () and Delete ().

If this principle is very holy, its implementation in this first attempt the east a little less, and is not really what is best in C + +. In introducing the function Delete () in the public interface of ResourceManager, we added a size constraint on the use of the New function (): pointer that returns must be systematically and released through Delete ().

While in some languages such as C, it is not already an obvious constraint to meet in any circumstance (an oversight is so fast arrived), it is particularly complex in C + + because of the support exceptions through language .
/ / Any function that uses an object Resource
void UseResource (ResourcePtr);

Void Test ()
(
     / / Maximum allowed 3 forums
     ResourceManager mgr (3);

     ResourcePtr r = mgr.New ();
     if (r)
     (
         UseResource (r);
         mgr.Delete (r);
     )
)

In the above example, if an exception is raised by the function UseResource (), the flow of classical performance is interrupted and the pointer returned by r ResourceManager: New () is never released. In other words, the resource is permanently lost!

Many objects languages (Java, C #, Python, PHP, ...) to remedy this problem using the keyword finally, but C + + is not. But it is possible to approach his philosophy of use through the construction following example:
/ / Any function that uses an object Resource
void UseResource (ResourcePtr);

Void Test ()
(
     / / Maximum allowed 3 forums
     ResourceManager mgr (3);

     ResourcePtr r = mgr.New ();
     if (r)
     (
         try
         (
             UseResource (r);
         )
         catch (...) / / pseudo finally block
         (
             mgr.Delete (r);
             throw / / revive the exception
         )
         mgr.Delete (r);
     )
)

As seen above, manage resources in this way is extremely heavy. Moreover, such as C + + does not collect automatically memory unlike languages offering keyword finally, such a construction would be used far more frequently than in these other languages, which would make the code simply illegible, and encourage the programmer to neglect this kind of "details". The use of the construction finally try ... is therefore not an appropriate response to a language like C + +.

Moreover, given as much work as a programmer client to ensure that our management objects to be valid is the sign of a very poor strength from our class ResourceManager. Indeed: a too basic use of this class is enough to jeopardise its reliability, and it is the programmer to ensure customer to maintain the stability of our system! But the C + + is reputed to allow writing programs robust. Yes, but how?

The approach C + +: RAII
The answer widespread C + + to the problem of resource management (and not just the particular case of memory management) called RAII. It is the acronym for Resource Acquisition Is Initialization, which can be translated as acquisition of resources during initialization. Actually, il ne faut pas trop focus within the meaning of this acronym, insofar as it does not reflect fully the concept he describes. The definition of the FAQ C + + said: This is a programming language to manipulate any resource (memory, file, mutex connection to a database, ...) through a local variable that will acquire this resource at its initialization and free at its destruction.

This idiom derives in fact benefit of a specific language C + +: the presence of a destructive class deterministic, in other words a function that is automatically and systematically executed when an object is destroyed. The principle of RAII is therefore to use this parity between the manufacturer and destructive to implement, the sauce C + + this time, the concept presented earlier: It is he who has allocated an object that would destroy it.

Reminder: the only case where the destroyer of an object is not known when the manufacturer has been is that the latter has removed an exception. Indeed, if a manufacturer raises an exception, the object is not considered to be constructed, and hence its destructiveness is not executed. Be vigilant on this point with the resources that you allocate in the constructor and free in the destructive: you may leak if an exception was closed shortly after their allowance while you are still in the constructor.

Presented otherwise, the RAII is to materialize a resource through which an object acquires this resource at its initialization, and ensure that it is to release its destruction, even if the programmer has not thought of. The manufacturer is therefore act according Init () and the destructive function Free (). The following example implements a class Resource traditionally managed and another class ResourceRAII whose design respects the concepts of RAII.
Resource class
(
public:
     / / Resource allocation: should be called
     / / First, and only once!
     bool Init ();
     / / Release of resources: not
     / / Forget to call once done!
     Void Free ();
    
     Void DoSomething ();
);

class RessourceRAII
(
public:
     RessourceRAII ();
     ~ RessourceRAII ();
    
     Void DoSomething ();
);

Void TestRessource ()
(
     Resource r;
     if (r.Init ())
     (
         try
         (
             r.DoSomething ();
         )
         catch (...) / / pseudo finally
         (
             r.Free ();
             Throw / / relaunch
         )
         r.Free ();
     )
     Else
     (
         / / Hours ... what to do, what's the problem?
     )
)

Void TestRessourceRAII ()
(
     RessourceRAII r / / exception waived if failure
     r.DoSomething ();
)

This example illustrates fairly well the vast simplification of use and robustness brought by the RAII. Because the principle of RAII wants as often as, if the object has been successfully established, then it is directly usable. If it fails to be, it can raise an exception to cancel its construction. The idea behind this behavior is: What would serve me an object that has not been able to build and is not therefore not usable? But of course, there are cases (as std:: ifstream for example).

Let's see now how to solve our problem initial objects Resource Management in addressing under this new angle.

Implementation: first test