Effective C + +: Clause 14: Copying performance in SME resource management

A

In terms of a clause auto_ptr and tr1::share_ptr fit heap-based resources. However, not all resources are heap-based. In other words, tr1::shared_ptr and auto_ptr are always suitable as resource managers. Management type.

If the mutex type is locked and unlocked by locking and unlock two sets of functions, we may want to behave like auto_ptr. Actively calls unlock to unlock when a smart type is destructor.

For example, the following code:

void Lock (mutex* pm); void unlock (mutex* pm); Class Lock{public:     Explicit Lock (mutex* pm): mutexptr (PM)     {         Lock (mutexptr);//Get Resources     }     ~lock () { Unlock (MUTEXPTR); }//Free resources private:     Mutex *mutexptr;};

What happens when we copy a lock object, such as the following:

Mutex m; Lock M11 (&m); Lock M12 (M11);  Perform copy behavior

The result is that it will be released two times for the same resource.

(ii) Solution:

Workaround One: disable replication.

Suppose the copy action is not reasonable for RAII class. We should forbid it!

Bye, clause 6. Declares a uncopyable class. Declare the copying operation of the Raii class as private to the Uncopyable class.

And then inherit it:

Class Lock:private uncopy{//prohibit copying, see clause 6 ...};

Workaround Two: The reference counting method (reference counting) is sacrificed to the underlying resource.

Sometimes we want to keep resources until the last user (an object) is destroyed.

The reference_counting copy behavior is usually achieved by simply referencing a TR1::SHARED_PTR member variable. But at this point, the default behavior of the tr1::shared_ptr is "when the reference count is 0 o'clock to delete its object", that is not the behavior we want, we want to do the release action is unlocked rather than deleted!

Fortunately, it is. Tr1::shared_ptr agrees that we specify the so-called "delete" (deleter), which is called when the number of references is 0 o'clock (this function does not exist in auto_ptr).

The second parameter that the delete is optional for the Tr1::share_ptr constructor:

Class Lock{public:  Explicit Lock (mutex* pm): mutexptr (PM, unlock);  Initializes the shared_ptr with a Mutex and takes the unlock function as the delete {lock (Mutexptr.get ());} private:tr1::shared_ptr<mutex> mutexptr; };

So later, when the number of references is 0 o'clock, the unlock function is called.

Assuming the unlock is not set, the object's resource is deleted, which is not the result we want.

Workaround Three: Copy Bottom Resource

The ability to have a random number of copies of a resource.

When you copy a resource management object, it is a " deep copy ." not only the pointer will be made a copy. And a new memory is created.

The standard string type is made up of pointers to the heap memory. When such a string object is copied, either the pointer or the memory it refers to will be copied in a duplicate.

This string shows "deep copy."

workaround four: transfer ownership of bottom resources

You want to make sure that there is only one Raii object pointing to an unprocessed resource, even though Raii is still copied.

The ownership of a resource is transferred from being copied to the target. This is in fact the auto_ptr meaning of the copy.

Please remember:

(1) copying a Raii object must replicate the resources it manages, so the copying behavior of the resource determines the copying behavior of the Raii object .

(2) The general and common RAII class copying behavior is: Suppress the copying, the reference counting method realization.

But other actions are also likely to be implemented.

Copyright notice: This article Bo Master original articles, blogs, without consent may not be reproduced.

Effective C + +: Clause 14: Copying performance in SME resource management