Effective use and design of the COM smart pointer-Clause 2: whether the reference count is

Clause 2: whether the reference count is
Programmers who use COM for development are often overwhelmed by the problems caused by interface reference counting. The reasons for the difficult problem of reference counting are also quite simple: in COM development, the customer only knows the component interface. When another interface is used after an interface is used, the customer cannot directly release the component because the customer does not know whether the two interfaces direct to the same component. Therefore, the life cycle of COM components cannot be conveniently controlled by customers.

So in order to solve this problem, the COM build uses reference count. Each component determines when to release the resources it occupies based on the reference count value. When a customer queries an interface from a component, the reference count value increases by 1. When the customer uses this interface, this reference value is reduced by 1. If the reference count of a component is reduced to 0, the component deletes itself from the memory.

You can manage the lifecycle of components reasonably through reference counting, but developers are also strictly required to follow these three simple rules [1 ]:

1. Call AddRef before returning. For the functions that return the interface pointer, apply the corresponding pointer to call AddRef before the return. These functions include QueryInterface and CreateInstance. In this way, when a customer obtains an interface from this function, he does not need to call AddRef.

2. Call Release after using the interface. Call the Release function of an interface after it is used.

3. Call AddRef after assigning values. When assigning an interface pointer to another interface pointer, you should call AddRef. In other words, the reference count of the corresponding component should be added after another reference of the interface is created.

Based on the above three principles, we need to compile the code for the following example:

View plaincopy to clipboardprint? Void SomeApp (IHello * pHello)
{
 
IHello * pCopy = pHello;
PCopy-> AddRef ();
OtherApp ();
PCopy-> Hello ();
PCopy-> Release ();
}
Void SomeApp (IHello * pHello)
{

IHello * pCopy = pHello;
PCopy-> AddRef ();
OtherApp ();
PCopy-> Hello ();
PCopy-> Release ();
}

These three rules seem simple, but if a programmer misses one of them at a certain time, it will confuse the reference count. After an error occurs, the program crashes directly because it has accessed the released resources. If you are lucky, the resource leakage will happen quietly.

We can see that, due to the introduction of reference counting, the life cycle of the COM component can be managed by itself, but it also makes the use of COM very dangerous. During use, each user must strictly and correctly call AddRef () and Release (). Once a problem occurs, the object cannot be released normally, or the object is deleted repeatedly, causing program crash. Therefore, you must be careful when using the COM interface.

We try to use a smart pointer to rewrite the above Code. CComPtr is used as an example,