Thread: When to use COM

When should I use COM and when should not?

COM == Component Object Model

COM is not just about memory handling, is it?

You use COM when you have to, and avoid it whenever doing so isn't more effort than using it.

That's my philosophy, anyway. It has served me well.

(The effort of using COM is considerable.)

Its better for me to ask: When you have to use COM?

When the functionality isn't available in any other form. For example, using DirectX (before the .Net wrappers were created). Using OLE. Using ActiveX. All these technologies are built on top of COM, and the only way not to use COM when using them is to look for some wrapper. (MFC wraps a lot of OLE and ActiveX functionality quite nicely.)

Why they are built on top of COM? MS should have a reason to do so? Andwhen should we implement our objects on top of COM?

Originally Posted by siavoshkc

Why they are built on top of COM? MS should have a reason to do so?

Because COM has some features that make it suitable for that kind of thing. Binary interoperability, for example. The fact that the interface-implementation design can hide marshaling code, which allows the implementation of an interface to sit in a different process than the one using the interface. (This is, for example, what happens when a web browser embeds Adobe Acrobat.)


Btw, writing COM interfaces is easy. Writing COM implementations is the really bad thing.

It is good place to ask another question: .Net is a wrapper for COM or does the job itself?

This is a question that I had a few years ago, and I didn't really "get it" until I started messing around with VBScript and VB. What you don't understand, is that Microsoft wasn't thinking about C++ when they wrote COM. Yes, COM is about binary-comatibility, which means you can write a component in one language, and then use it from another.

In practice, this means you can write components in C++, using COM, packaging them into a DLL, and then make them callable from VBScript. This makes a lot of sense, because VBScript is a relatively limited language. So COM via C++ is basically a way to extend the (VBScript) language. Also, lots of times people write components in C++, and the sole purpose of those components is to be reused in VB code. For example, writing the GUI might be easy in VB, but the actual processing logic might already be written in c++, or it might be more efficint in c++, or it might just be easier to code in c++. Whatever the reason, you could write the front-end GUI code in VB, and the processing/business logic in a c++ com component.

So what you'll find, if you research VB or VBScript, is that using COM components in those langauge is very easy. Using COM in C++ is not so easy, and this is my opinion, but I think it's because Microsoft never really intended for it to be that way. If you want to get a feel for this, just try writing two programs that use ADO. One in C++, and the other in VBScript.

So back to your question, when do you use COM? For me, the answer is if you are writing some kind of reusable component that is going to be called from another language, and that language is probably VB.

For your .NET question, that's another Framework, and no it doesn't necessarily use COM underneath. There is a way to make use of COM from within .NET, which is called "pinvoke", and there is a way to make a .NET object behave as if it was a COM object (called COM Callable wrappers). But in general, they're two different technologies. In fact, I think MS encourages newer development to use .NET...they might even be calling COM "legacy" at this point...

Originally Posted by siavoshkc

It is good place to ask another question: .Net is a wrapper for COM or does the job itself?

If you're still wondering about DirectX, the answer is yes: Managed DirectX is just a wrapper around the native COM DirectX.

In general, no, COM and .Net have nothing to do with each other. Except that the COM-.Net interop services can make COM objects look like .Net classes to .Net and .Net classes like COM objects to native code.