Analysis and Research on C ++ resource management content

The following describes how to manage C ++ resources. First, you must understand the concept of C ++, the so-called C ++ language: it is a widely used computer programming language, and C ++ has become one of the most complex in today's mainstream programming languages.

First, we will briefly introduce RAII. The basic method of this idea is to write a guard class for a resource to be used and request resources in the constructor of this class, release resources in the destructor. For example, if we want to manage a mutex lock, the possible method is:

 
 

  
  
struct  lock_guard  
  
  
  {          
  
  
    lock_guard() { lock ();}   
  
  
    ~ lock_guard() {unlock();}   
  
  
   } ; 
 
 

After that, the memory management method used for this object is equivalent to the memory management method used for this mutex lock. With RAII, we can only discuss the management of memory resources in the future. Other resource management methods can also be implemented using RAII.

Now we have naturally obtained three methods of resource management: heap-based dynamic mode, stack-based automatic mode, and global mode. It is worth mentioning that the last two methods, which are not prone to errors, can actually meet most of the resource management requirements.

Because most resources belong to the get-use-release type, such as many synchronization objects, file locks, and many GDI objects in WinGDI. We lack management. Only a few resources that are obtained at a time, owned by multiple environments, and released at one time are available.

Back to the memory model, one thing that makes it impossible for us to equate memory with other resources, in turn, and equate other resources with memory) is loop reference.

A memory can hold the reference pointing to B memory, and B memory can also hold the reference of A memory in turn. Loop reference causes memory management to fail to use "whether there is a reference pointing to this memory" to identify whether a memory can be recycled. Thus, an excellent management method is lost. However, in the absence of circular references, we still have very simple and efficient management methods. That is, the reference count.

Reference counting is an excellent method for memory management without cyclic reference. It is lightweight, efficient, real-time, and controllable. In addition, in the C ++ resource management, the reference count is very mature, and you only need to use boost. shared_ptr or other unofficial reference counting pointer libraries, and it is reported that C ++ resource management is likely to boost. shared_ptr is included in the standard library.

The principle of reference counting is that an object can be released if there is no pointer or reference pointing to it. Which situations of resource management problems can reference counting be handled? First, for single-direction resource management, that is, multiple A entities have one B, but B does not depend on A. For example, multiple objects share one log ), the reference count is very suitable.

Secondly, for situations with A reaction, that is, one or more entities of A have one or more entities of B, and B also has references to these entities of, however, the lifetime of B is still determined by the lifetime of A. For example, the parent window has several subwindows, and the Child window has A parent pointer pointing to the parent window.

However, the lifetime of the Child Window is determined by the lifetime of the parent window. In this case, A can use the reference count pointer for B, while B can use the native normal pointer for, the same can solve the problem well. All that is left is the cycle dependency of the lifetime. If AB holds the references of the other party and both the AB and the other party depend on each other, the reference count cannot be solved.

However, if you think about it, you will find that this situation is almost impossible in C ++ resource management. There are only two consequences for the survival cycle dependency: either the destructor in The Destructor A and B goes down), or neither of them will leak ).

• Analysis on C ++ Parameters
• C ++ Class Definition Format description in C ++
• How do I call C ++ functions?
• Dialysis C ++ array type
• Understanding the basics of C ++ pointers

Both of them will not occur in normal programming. So even if we only use reference counting, we can solve almost all resource management problems. Now let's look back at the built-in gc language such as Java/C. Because gc is used in such a language, the Destructor is inevitably abandoned. Why does gc conflict with the Destructor?

A gc generally hopes that the whole process will be atomic during garbage collection, but the Destructor will destroy this point. If you want to execute code when releasing the memory, this will inevitably have a devastating impact on the entire gc environment.

Without destructor, these languages cannot implement RAII. That is to say, their C ++ resource management can only be managed by memory. For other resources, Java and so on must be manually released. Although C # provides the with keyword to alleviate this problem, it still cannot be completely solved.