VC for COM programming must master the Theoretical Knowledge (ii) __ Programming

Second, VC for COM programming, you must master what COM theory knowledge

I have seen a lot of people learn com, after reading a book on the principle of COM more understand, COM also so much, but just do not know how to program, I have this situation, I have experienced such a stage came. To learn the basics of COM, I recommend the book is the "COM Technology Insider." But it is not enough to read such a book, our ultimate goal is to learn how to use COM to program, rather than desperately studying the mechanism of COM itself. So I personally think that the basic principles of COM do not need to spend a lot of time to inquisitive, there is no need, is a thankless task. In fact, we only need to master a few key concepts is enough. Here I list some of the key concepts I think I need to master in VC programming. (This is all in the C language conditions of the COM programming method)

(1) The COM component is actually a C + + class, and the interface is a pure virtual class. Component derives from an interface we can simply describe what COM is, in pure C + + syntax:

Class Iobject { Public Virtual Function1 (...) = 0; Virtual Function2 (...) = 0; .... }; Class Myobject:public Iobject { Public Virtual Function1 (...) {...} Virtual Function2 (...) {...} .... };

Do you see it clearly. Iobject is what we often say is the interface, MyObject is called the COM component. Remember that interfaces are all pure virtual classes, and that they contain functions that are pure virtual functions, and that they do not have member variables. A COM component is a derived class that inherits from these pure virtual classes, and it implements these virtual functions. From the above also can be seen, the COM component is based on C + +, especially important is the concept of virtual function and polymorphism, COM all functions are virtual functions, must be through the virtual function table vtable to call, it is extremely important, must always bear in mind. To get a clear idea of what a virtual function table looks like, copy the following example diagram from the COM + technical Insider:

　　

(2) COM components have three basic interface classes, respectively, the IUnknown, IClassFactory, idispatchcom specification stipulates that any component, any interface must inherit from IUnknown, IUnknown contains three functions, Respectively, QueryInterface, AddRef, release. These three functions are extremely important, and their order of arrangement is immutable. QueryInterface is used to query the other interfaces of the component implementations, in other words, to see what other interface classes are in the parent class of the component, AddRef to increase the reference count, and release to reduce the reference count. Reference counting is also a very important concept in COM. In general, it is easy to understand that a COM component is a DLL that is loaded into memory when it is used by a client program.

On the other hand, a component is not only for you, there may be a lot of programs to use it at the same time. But in fact the DLL is only loaded once, that is, there is only one COM component in memory, and who is releasing the COM component. By the client program. No, because if you release the component, that's how others use it, so you can only be responsible for it by the COM component itself. So there's the concept of reference counting, and COM keeps a count of how many people are currently using it, every call count plus one, less a customer use it to minus one, when the last client released it, COM know that no one used it, its use is over, then it will release itself.

Reference counting is a very error-prone place in COM programming, but fortunately VC of various kinds of class library has basically put AddRef call to implied, in my impression, I have not programmed the time to call the AddRef, we only need to call release when appropriate. At least two times to remember to call release, the first is after calling QueryInterface, and the second is to call any function that gets a pointer to an interface, and remember to check the MSDN to determine if the AddRef is called inside a function. If so, the responsibility for calling release will be yours.

The implementation of these three functions of IUnknown is very normative but also very cumbersome, error prone, fortunately, we may never need to implement them ourselves.

The role of iclassfactory is to create COM components. We already know that a COM component is actually a class, and that's how we normally instantiate a class object. It's a ' new ' command! It's simple, and so is the COM component. But who's going to new it? It is impossible to be a client, because the client program cannot know the class name of the component, and if the customer knows the component's class name the reusability of the component is going to be a big discount, in fact the client only knows a 128-digit string representing the component, which will be introduced again. So the customer can't create the component on its own, and consider if the component is on a remote machine and you can get a new object. So the responsibility to create the component is given to a single object, which is the class factory.

Each component must have a related class factory that knows how to create a component, and when a client requests an instance of a Component object, the request is actually given to the class factory, which creates a component instance from the class factory and then hands the instance pointer to the client program. This process is particularly useful when creating components across processes and remotely, because this is not a simple new operation, it has to be scheduled, and these complex operations are given to the class factory object to do.

IClassFactory one of the most important function is CreateInstance, as implies is to create a component instance, in general, we will not call it directly, API functions are encapsulated it for us, only in some special cases, we will call it ourselves, This is the VC write COM components of the benefits, so that we have more control opportunities, and VB to give us such a chance is too little too little.

IDispatch is called the dispatch interface. What is its role. There are many other languages in this world besides C + +, such as VB, VJ, VBScript, JavaScript and so on. It can be said that if there are not so many messy languages in the world, there will be no IDispatch. :-) We know that COM components are C + + classes, is rely on the virtual function table to call the function, for VC is no problem, this is designed for C + +, the previous VB is not, now VB can also use the pointer, but also through vtable to call the function, VJ also can, but still some languages do not, That's the scripting language, typical of VBScript, JavaScript. The reason is that they do not support pointers, even the pointer can not use how to use polymorphism Ah, how to tune these virtual functions ah. Oh, no way, also can not ignore these scripting language, now the Web page is used in these scripting languages, and distributed applications is a major market for COM components, it has to be called by these scripting languages, since the way the virtual function table is not workable, we can only find another method. When the Times make heroes, IDispatch come into being. :-)

Dispatch interface to each of the functions of each attribute is numbered, the client program to call these function properties of the time to pass these numbers to the IDispatch interface on the line, IDispatch again according to these numbers call the corresponding function, nothing more. Of course, the actual process is far more complex than this, when given a number can let others know how to call a function that is not the day night pool, you have to let people know what parameters you want to call the function, what type of argument and what to return, and it's a big headache to deal with these problems in a uniform way. The main function of the IDispatch interface is invoke, which is invoked by the client, and then invokes the corresponding function, and if you look at MS's class library, the code that implements invoke will marvel at the complexity of its implementation because you have to consider the various parameter types. Luckily we don't have to do it ourselves, and we may never have the chance. :-)

(3) dispinterface interface, dual interface and custom interface

This section does not seem appropriate here, as this is the term used in ATL programming. I am here mainly to talk about the advantages and disadvantages of automation interface, it might be better to explain these three terms, and sooner or later, I will be able to explain them in a popular way, perhaps not so precise as to describe the algorithm in pseudocode. -:)

The so-called Automation interface is the interface implemented with IDispatch. We have already explained the role of IDispatch, the advantage of which is that scripting languages like VBScript, JavaScript can also use COM components, so basically do with language-independent of its shortcomings are mainly two, the first is slow and inefficient. This is obvious, through the virtual function table can call the function, and through invoke is equal to the middle of the procedure, especially the need to convert the function parameters to a canonical format to call the function, delay a lot of time. So we all want to call a function in a vtable way to get high efficiency if it's not a necessity.

The second disadvantage is that you can only use the so-called automated data types that are defined. If you don't need to IDispatch what type of data we can use, VC will automatically generate the corresponding dispatch code for us. And you can't do it with an automated interface, because the implementation of invoke code is VC written in advance, and it can not anticipate all the types we need to use, it can only be based on some commonly used data types to write its processing code, but also to consider the different languages of the data type conversion problem. So the VC Automation interface generated scheduling code only for the data types that it prescribes, of course, these data types are rich enough, but can not meet the requirements of custom data structures. You can also write your own scheduling code to handle your custom data structures, but this is not an easy task.

Considering the shortcomings of IDispatch (it also has a disadvantage, is the use of trouble, now generally recommended to write dual interface components, called Dual interface, is actually inherited from the IDispatch interface.) We know that any interface must inherit from IUnknown, and the IDispatch interface is no exception. The interface that inherits from IDispatch actually equals two base classes, one is IUnknown, the other is IDispatch, so it can invoke the component in two ways, either by IUnknown calling the interface method with a virtual function table, or by IDispatch :: Invoke automated scheduling to invoke this has a lot of flexibility, this component can be used in both C + + environment and scripting language, while meeting the needs of all aspects.

In contrast, dispinterface is a pure automation interface that can be simply viewed as a IDispatch interface (although it is not), and this interface can only be invoked in an automated way, and COM component events typically use this form of interface.

The custom interface is a class derived from the IUnknown interface, and obviously it can only invoke the interface in the form of a virtual function table.

I have set up a blog, the article has been transferred to personal blog, Welcome to communicate!

The theory knowledge must be mastered in COM programming with VC (II.)
Http://www.jeanva.cn/post/48.html