Negative tive C ++ Clause 14: copying actions in resource management

Not all resources are heap-based. For such resources, intelligent pointers such as auto_ptr and shared_ptr are often not suitable for resource management. You may need

Create your own resource management class.

For example, the mutex object processing type is mutex. The lock and unlock functions are available.

Void lock (mutex * PM );
Void unlock (mutex * PM );
Class lock {
Public:
Explicit lock (mutex * pm)
: Mutexptr (PM );
{
Lock (mutexptr); // obtain resources
}
~ Lock () {unlock (mutexptr);} // release resources
PRIVATE:
Mutex * mutexptr;
};

What happens when a raiI object is copied? Most users may choose the following two possibilities:

 

1. Copy prohibited. In many cases, it is not reasonable to allow raiI object replication. Lock looks like this:

Class lock: Private uncopy {// copying prohibited. For details, see section 6.

...

};

2. Provides reference counting for underlying resources ). Sometimes we want to retain resources until the last user (an object) of the resource is destroyed.

Generally, you only need to reference A tr1: shared_ptr member variable to implement the reference_counting copy action. However, in this case, tr1 :: the default behavior of shared_ptr is "Delete the things that are specified when the number of references is 0", which is not what we want. Fortunately, tr1: shared_ptr allows us to specify the so-called "Er", which is called when the number of references is 0 (this function does not exist in auto_ptr ). The deleteer is a dispensable second parameter for the tr1: javas_ptr constructor:

Void lock (mutex * PM );
Void unlock (mutex * PM );
Class lock {
Public:
Explicit lock (mutex * pm)
: Mutexptr (PM, unlock); // initialize shared_ptr with a mutex and use the unlock function as the deleteer
{
Lock (mutexptr. Get ());
}
~ Lock () {unlock (mutexptr );}
PRIVATE:
STD: tr1: shared_ptr <mutex> mutexptr;
};

In this example, lock class no longer declares the destructor. The class destructor (whether automatically generated by the compiler or defined by the user) automatically calls the destructor of its non-static member variable (mutexptr in this example. The mutexptr destructor will automatically call the tr1: shared_ptr Delete tool (unlock in this example) when the number of mutex references is 0)

3. Copy the bottom resource. You can have any number of copies of a resource. When copying a resource management object, it is "deep copy ".

The standard string type is composed of a pointer to heap memory. When such a String object is copied, a replica is copied regardless of the pointer or memory. Such a string shows "Deep copy ".

4. Transfer the ownership of the bottom resource. You want to ensure that only one raiI object points to an unprocessed resource, even if raiI is replicated. Resource ownership is transferred from being copied to the target object. The meaning of auto_ptr replication.

To copy a raiI object, you must copy the resources it manages. Therefore, the copying behavior of the resource determines the copying behavior of the raiI object.