Effective use and design of COM smart Pointers-clause 11: Create resource and Query Interfaces in a type-safe manner

Clause 11: create resources and Query Interfaces in a type-safe manner more terms go to source: http://blog.csdn.net/liuchang5

The following method is not uncommon in the compilation of COM components:

Void func () {IX * pix = NULL; hrretcode = cocreateinstance (clsid_mycomponent, null, clsctx_inproc_server, iid_ix (void **) pix // amount ~~ Ship in the gutter ~ ); Assert (hrretcode); pix-> ixfunction ();}

What will happen to the above Code? Its behavior is uncertain, and in most cases it is wrong. The reason is that the functions used when creating COM components or interface queries are not of type security.

In this case, you may think that we should use smart pointers to avoid this problem. Because smart pointers cannot be forcibly converted to the (void **) type. It seems that this can make your type safer, but the error still occurs:

Void func () {ccomptr <IX> Spix = NULL; hrretcode = cocreateinstance (clsid_mycomponent, null, clsctx_inproc_server, iid_iy // amount ~~ An error occurs here (void **) & pix); Assert (hrretcode); pix-> ixfunction ();}

Fortunately, the assertions later can give feedback on errors in a timely manner, but if we have a better way to avoid this problem, why not?

The best way to solve this problem is to use the interface query method provided by smart pointers:

Void func () {ccomptr <IX> Spix = NULL; // IID is bound to Spix when a smart pointer is created. cocreateinstance (clsid_mycomponent); Assert (Spix); pix-> ixfunction ();}

Yes, that's right. We recommend that you use smart pointers, but we hope that you can use the functional functions provided by smart pointers to create and query resources. It not only makes the code concise, but also makes your code more secure in terms of type.

Sometimes, we usually consider the portability and compatibility of a class when considering its design. This leads us to exercise caution when using compiler-related features. Or more often, we can avoid some of the features that the compiler brings to us to pursue portability and compatibility with different platforms.

However, before considering these problems, we should first consider the proper execution of the program. A program that allows errors, even if it can be transplanted at will, does not make much sense.

First, let's take a look at the following interface and guid definition:

// {994D80AC-A5B1-430a-A3E9-2533100B87CE}DEFINE_GUID(IID_ICALCULATOR,             0x994d80ac, 0xa5b1, 0x430a, 0xa3, 0xe9, 0x25, 0x33, 0x10, 0xb, 0x87, 0xce); class ICalculator public : IUnknown{public:    virtual HRESULT STDMETHODCALLTYPE Add(        const int nNum1,         const int nNum2,         int *pnSum    ) const = 0;        virtual HRESULT STDMETHODCALLTYPE Sub(        const int nMinuend,        const int nSubtrahend,         int *pnQuotient    ) const = 0;};                    

There is no problem with this, and there will be no problems when using some smart pointers. For example, _ com_ptr_t allows you to bind the IID and the interface in the following way when you specifically define a smart pointer.

// Use the following method to bind the IID and interface to a smart pointer: _ com_smartptr_typedef (icalculator, iid_icalculator); hresult calculaltor () {icalculatorptr spcalculator (clsid_calculator ); // constructor can create COM component int nsum = 0; spcalculator-> Add (1, 2, & nsum); Return s_ OK ;}

In this way, even in the case of specialization, it is easier to search and modify the IID and the corresponding icalculator. Once the smart pointer is declared, the interface pointer and IID are bound together. In subsequent development, you do not need to consider the issue of matching between them.

However, if the above interface declaration and ccomptr are used in combination, the situation is very different. Your program may not be compiled at all:

Void func (void) {ccomptr <icalculator> pcalculator = NULL; // The compilation fails. The prompt is: no guid has been associated with this object hrretcode = pcalculator. cocreateinstance (clsid_calculator,); Assert (hrretcode); spcalculator-> dosomething ();}

We can see that ccomptr and _ com_ptr_t use two different methods to solve the problem of IID and interface binding. Ccomptr requires developers to bind the IID to the interface when declaring the interface. But _ com_ptr_t can decide whether to use _ UUID as needed.

Therefore, to be compatible with these two smart pointers, we need to use the following method when defining them:

// Use the security mechanism provided by the compiler to specify iidinterface _ declspec (UUID ("identifier") icalculator: iunknown {virtual hresult stdmethodcalltype add (const int nnum1, const int nnum2, int * pnsum) const = 0; virtual hresult stdmethodcalltype sub (const int nminuend, const int nsubtrahend, int * pnquotient) const = 0 ;};

If you understand IDL, it is more reasonable to use IDL to define the interface and bind the IID with it. But for the time being, this will make the things we want to express in the example clearer and clearer.

Yes, although the portability is a little lower, it makes the interface more secure and convenient to use. You do not need to specify the corresponding IID for the interface each time you query the interface and create the COM component. This is often the cause of errors. We need to first consider how to write security code that is difficult to produce errors, followed by its compatibility.

If you want to know how to solve the porting and compatibility discussions brought about by UUID and _ uuidof. For more information, see section 25.