C ++ pointer description Management

C ++ language has developed to this day and relies on C ++'s own freedom. Most of it is reflected in its flexible use of C ++ pointers, since its initial development in pascal, object pascal and C ++ are no inferior to the pointers in C language.

The possession of a given resource is an object or code that is responsible for releasing the resource. Two levels of ownership are separated: automatic and explicit. If an object is released, it is guaranteed by the language mechanism, this object is automatically owned.

For example, if an object is embedded in another object, other objects are required to be cleared. The external object is treated as the owner of the embedded class. Similarly, the release failure of every object created on the stack as an automatic variable) is guaranteed when the control flow leaves the scope defined by the object.

In this case, the action is taken as the owner of the object. Note that all automatic ownership is compatible with other language mechanisms, including exceptions. No matter how you exit the scope-normal process control exit, a break statement, a return, a goto, or a throw-Automatic resources can be cleared.

So far, everything is fine! The problem occurs when pointers, handles, and abstractions are introduced. If you access an object through a C ++ pointer, for example, if the object is allocated in the heap, C ++ does not automatically pay attention to its release. Programmers must explicitly release these resources using appropriate program methods. For example.

• Analysis on the implementation method of C ++ Interface
• How to better learn the C ++ language?
• Resolve the problems encountered when learning C ++
• Introduction to C ++
• C ++ functions in C ++

If an object is created by calling new, it needs to be recycled using delete. A file is opened using CreateFile (Win32 API) and must be closed using CloseHandle.

The Critical Section that uses EnterCritialSection. LeaveCriticalSection is required to exit. A "Bare" C ++ pointer, file handle, or critical zone State has no owner to ensure they are finally released. The basic prerequisite for resource management is to ensure that each resource has its own owner.

A c ++ pointer, a handle, and a critical section state will own the owner only when we encapsulate them into objects. This is our first rule: allocate resources in the constructor and release resources in the destructor. When You encapsulate all resources according to the rules, you can ensure that there is no resource leakage in your program. This is obvious when the encapsulated Object Encapsulating Object is created in the stack or embedded in other objects. But what about those dynamic application objects?

Don't worry! Any dynamic application is regarded as a resource and encapsulated according to the method mentioned above. The chain of the encapsulated object of this object has to be terminated somewhere. It ends at the highest level of owner, automatic or static. These are the guarantees for releasing resources when the scope is left or the program is released.

The following is a classic example of resource encapsulation. In a multi-threaded application, the problem of sharing objects between threads is solved by connecting such an object to the critical section. Each customer who needs to access Shared resources needs to obtain the critical section. For example, this may be the implementation method of the critical section in Win32.

 
 

  
  
class CritSect  
  
  
{  
  
  
friend class Lock;  
  
  
public:  
  
  
CritSect () { InitializeCriticalSection (&_critSection); }  
  
  
~CritSect () { DeleteCriticalSection (&_critSection); }  
  
  
private  
  
  
void Acquire ()  
  
  
{  
  
  
EnterCriticalSection (&_critSection);  
  
  
}  
  
  
void Release ()  
  
  
{  
  
  
LeaveCriticalSection (&_critSection);  
  
  
}  
  
  
CRITICAL_SECTION _critSection;  
  
  
}; 
 
 

The smart part here is to ensure that every customer entering the critical section can leave. The status of "entering" critical section is a resource and should be encapsulated. The package is usually called a lock ).