What is the advantage of using COM in a simple DLL?

Question

Suppose you only work in the C ++ world (an interlanguage interface is not required). What advantages / disadvantages do you see when using COM instead of a simple base DLL? Do you think that using COM is worth it if you are not going to use the interface from different languages?

Answer 1

Everyone mentions things that are in the COM plus column. I mentioned a couple of distractions.

• When you deploy your system using COM, you need to register COM servers (whether in proc or out-of-proc) during configuration and unregister upon removal. This can slightly increase the complexity of your configuration system and, as a rule, requires a reboot if the user does not first hide the running processes.

• COM is slow compared to other standard ways of doing the same thing. This comment is likely to cause a lot of hatred, and maybe some lowering voices, but the fact is that at some point you will need to collect data, and it's expensive.

• According to the COM Rules, after publishing an interface, it can never be changed. This in itself is not negative, and you can even claim that it forces you to do a thorough design before submitting the interface. But the truth is that there is no such thing as never before, and they change in the interfaces of production code. You will undoubtedly need to either add methods or change the signatures of existing methods. To do this, you either have to break COM rules, which have bad consequences, or follow COM rules, which are harder than just adding a parameter to a function like yours with an astral DLL.

Answer 2

COM can be useful in plain old C ++ for:

• Interprocess communication
• Plugin architecture
• Late Binding Scenarios
• "Much, many, more ..." (tm)

However, if you do not need it, do not use it.

Answer 3

With a DLL, you can get a much closer connection, while COM very accurately limits the interaction. This is the root of both advantages and disadvantages!

You get more power and flexibility (for example, inherit from classes defined in the DLL, not feasible in COM), but the dependency is much stronger (you need to rebuild the user for certain changes in the DLL, etc.).

It is often especially important that all DLLs and EXEs must use the same type of library and runtime parameters (for example, all that are dynamically associated with a non-debugging multi-threaded version of msvcrt* , for example), it is impossible to rebuild only one use the debug version without occurrence very likely mistakes!).

A weaker COM connection is therefore often preferable if you do not need closer interactions in a particular case (for example, a structure that definitely requires user code to inherit from its classes should be a DLL).

Answer 4

If you can avoid this, do not use it. In my last project, COM put a lot of restrictions on the C ++ interfaces used. Imagine that you cannot just pass std :: string, but you must use an array of characters. In this case, you create a string and then copy it to an array that can be processed by COM.

You can also use a very limited set of fundamental types, have fingerprints and patented memory management. You cannot use new / delete, but you must use your own COM functions.

You also cannot just throw an exception, but you must initialize some IErrorInfo COM interface, which will be deleted on the other end.

So, if you do not need it, do not use it. It definitely instills your design. And if you need it, try to evaluate other possibilities of interaction: boost :: interprocess, zeroc ice ...

Hi,

Hovhannes

Answer 5

• Registration and discovery
• No in the process
• Remote call

- These are a few additional features that you have. Even transactional support can flow without the need for COM support these days.

Answer 6

The IUnknown interface is a good basic level for support in any case - it gives you the ability to add functions without breaking old clients (QueryInterface) and universal reference counting. You can implement this without buying everything in COM.

Then, whenever you add a function to a class, if you use the COM interface for this, you at least get an interface that is known - for example IDispatch, if you want to use reflection functions.

Your only delta from being called by another language would then be a registry and a factory class.

Answer 7

Since interfaces are not dependent on any particular DLL, at its simplest level, an approach like COM at least frees you from changing the dll serving the interface under the hood without having to recompile the application against the new dll name.

Using full COM with installed MIDL interfaces and dummy proxies means that you can use COM to control the security flow in the process, interprocess communication on one PC, or even connect to a COM server object on a remote PC.