Auto_ptr and tr1: The concept of shared_ptr is manifested in heap_based resources. However, not all resources are heap_based. For non-heap_based resources, you need to establish your own resource management class.
Assume that the Mutex objects (mutex objects) type is Mutex by using the c api function. There are two functions: lock and unlock.
Void lock (Mutex * pm); // lock the Mutex void unlock (Mutex * pm) referred to by the pm; // unlock the Mutex
To ensure that you will never forget to unlock a locked Mutex, create a Lock class to manage the Lock. The basic structure of such a class is governed by the RAII code, that is, "resources are obtained during the construction and released during the analysis ":
Class Lock {public: explicit Lock (Mutex * pm): mutexPtr (pm) {Lock (mutexPtr); // obtain resources }~ Lock () {unlock (mutexPtr); // release resources} private: Mutex * mutexPtr ;};
The customer's usage of Lock complies with the RAII method:
Mutex m;... {Lock ml (& m); // Lock the Mutex...} // automatically unlock the Mutex at the end of the block
If the Lock Object is copied at this time:
Lock ml1 (& m); // Lock mLock ml2 (ml1); // copy ml1 to ml2. What will happen?
There may be two options:
Prohibit Replication: In many cases, it is not reasonable to allow RAII object replication:
If the copy constructor and value assignment operator are not defined as needed, the result is generally: Non-memory resources are created once and released multiple times.
Prohibited method: declare the copying operation as private.
Class Lock: private Uncopyable // prohibit copying. See Clause 6
{Public:... // as before };
If replication is required, it is necessary to redefine the copy constructor and the value assignment operator.
Writing them is a problem. The specific solution depends on actual needs,You can use a deep copy, a reference counting mechanism similar to shared_ptr, or transfer ownership.
Reference counting method for underlying resources:
When copying a RAII object, increase the number of referenced resources. Example: shared_ptr.
The default behavior of shared_ptr is "Delete the specified object when the number of references is 0", but the action we want in the above example is to unlock rather than Delete the object.
Fortunately, shared_ptr allows you to specify the "deleteer ":
Class Lock {public: explicit Lock (Mutex * pm): mutexPtr (pm, unlock) // initialize shared_ptr with a mutex, and use the unlock function as the deletor {lock (mutexPtr. get ();} // terms 15 ~ Lock () {unlock (mutexPtr);} // release the resource private: std: tr1: shared_ptr <Mutex> mutexPtr ;};
Deep copy:
Some standard string types are composed of pointers pointing to heap memory. Such a String object is copied, and a replica is produced regardless of the pointer or memory. Such a string shows deep replication.
Transfer bottom resource ownership:
Auto_ptr indicates that the RAII object is copied, and the resource ownership is transferred from the replicated object to the target object.