One:
When COM thinks no longer uses an object, the COM itself does not automatically attempt to remove the object from memory. Instead, the programmer of the object must remove unused objects. The programmer determines whether the object can be removed according to the reference number.
COM uses the number of references to interfaces on the IUnknown method, AddRef, and Release management objects. The general rules that call these methods are:
Whenever the client receives an interface pointer, you must call AddRef on that interface.
Whenever the client has completed the use of the interface pointer, it must call Release.
In a simple implementation, each AddRef call will increase while each Release call reduces counter variables in the object. When the count returns to zero, this interface no longer has any users and can remove it from memory.
A reference count can also be implemented to count each reference to the object (not a single interface). In this case, each AddRef and Release calls are delegated to the center implementation on the object, and the entire object is released by Release when the reference number of the object reaches zero.
Note that when using a New operator to construct a CCOMOBJECT derived object, the reference number is 0. Therefore, you must call AddRef after successfully created a CComObject derived object.
QueryInterface
Although there is an object that can be used statically (before the object is instantiated) indicates the mechanism it provides, the basic COM mechanism will use an IUNKNOWN method called QueryInterface.
Each interface is derived from iUnknown, so each interface has a queryinterface implementation. No matter what is achieved, the method uses an interface (the caller requires a pointer to the interface) of the IID query object. If the object supports the interface, QueryInterface retrieves pointers to this interface, and also calls AddRef. Otherwise, it returns the E_NOIInterface error code.
Please note that you must follow the reference count rules forever. This pointer should not be used if the Release to the interface pointer will be reduced to zero. Sometimes you may need to get the weak reference to the object (ie you may want to get a pointer to one of the object interface but do not add a reference number), but you don't call QueryInterface first and then call Release to achieve this. The pointer acquired in this way is invalid and should not be used. This will become more apparent when defined _ATL_DEBUG_INTERFCES, so defining the macro is a useful method for finding a reference count.
Seal processing
The COM package processing technology allows an interface to be disclosed by an object in another process in one process. In the sealing process, COM provides (or provided by interface implementors) with the following function: compressing the parameters of the method into the format that can be moved between the processes, and decompressed these parameters at the other end, can be in progress The movement also includes a process that can run on other computers through a line. Similarly, COM must perform these same steps back to the call.
Note When the interface provided by the object is used in the same process as the object, it is generally not necessary to perform a package. However, it may be necessary to be sealed between threads.
polymerization
Sometimes, the implementation of the object hopes to take advantage of the services provided by another precomblative object. Moreover, it hopes that the second object is displayed as the inherent component of the first object. COM reaches these two goals by inclusion and aggregation.
The aggregation means that the (external) object creates a part of the (internal) object as part of its creation process, and the interface of the internal object is disclosed by the external object. Objects allow itself to be polymerizable or non-polymerrable. If the object is polymerizable, it must follow certain aggregation rules to work correctly. Mainly, all IUNKNOWN method calls that are included in the object must be delegated to the included object.
two:
IUNKNOWN interface two important features:
Life control
The client can only communicate with the COM object through an interface. Although the client program can control the details of the object, it is to control the existence or not.
If the customer's operation is completed, the object is no longer needed, and the object must be released in time.
IunkNown introduces a reference count (Reference Count) method, which effectively controls the object survival cycle.
2. Interface query
At the initial moment, the client is unlikely to get all interface pointers of the object, which only has an interface pointer. If the client needs other pointers, how do it get another interface pointer through this interface pointer? IUNKOWN uses the "QueryInterface method to complete the jump between the interfaces.
IDL description
Interface IUnknown
{
HRESULT QueryInterface ([in] refiid IID, [OUT] void ** PPV);
Ulong AddRef (Void);
Ulong Release (Void);
}
C description:
Class iunknow
{
PUBLIC:
Virtual HRESULT _STDCALL QueryFace (const IID & IID, VOID ** PPV) = 0;
Virtual ulong _stdcall addref () = 0;
Virtual ulong _stdcall release () = 0;
}
