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

Source: Internet
Author: User

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

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.