Comparing pimpl idiom with Microsoft COM

Question

I know this topic is somewhat off-topic on StackOverflow. But I just cannot think of another more appropriate place to post it, and I really want to gather opinions from you guys.

Recently, I come across the pimpl idiom. I think it is related to Microsoft's Component Object Model (COM), and trying to make a comparison of the two. Such a comparison should be beneficial to the understanding, and I want to make sure that I get it right. So, if you find any misunderstanding in the comparison or have any additions to make, feel free to post it as an answer. The comparison is as follows:

Similarities:

1. Both of the two decouple interface from implementation at the binary level. Therefore, changing the implementation does not require recompiling user code.

Differences:

1. Since COM interfaces use virtual functions only, user code can be compiled and linked independently without referencing the implementation in any way. This enables the binary module (i.e., .dll on Windows and .so on Linux) of the implementation to be dynamically loaded at demands during process running (e.g., through explicit calls to LoadLibrary() on Windows platforms). With the pimpl idiom, class methods are not necessarily virtual, and user code linking has to reference the implementation, or there will be unresolved external symbol references. Besides, loading of the implementation binary module has to be done implicitly at process startup by the operating system loader.

2. The pimpl idiom allows instantiating implementation objects directly in user code. With COM, however, a factory function has to be used to obtain a pointer to the implementation object.

3. While COM is designed to be compiler-neutral, the pimpl idiom is not because of name-mangling and such.

Answer 1

Both are voluntary restrictions on allowed constructs in the code, to achieve a particular goal.

The common element of both is that they enforce a hard distinction between pure data structures (that cannot contain methods) and object interfaces (that cannot contain data members).

COM, in addition, also requires data and interface parameters to be serializable (with some exceptions, e.g. IUnknown is not), and also introduces a second naming convention for classes using GUIDs and a binary interface specifying data structure and virtual function table layout.

The pimpl idiom also uses factory classes -- the pimpl class creates the actual implementation. COM just explicitly calls them factory classes, and permits reuse of objects (for example, it is legal for a factory class providing a singleton to simply return a reference to itself).

Personally, I find the pimpl idiom unnecessary. The class holding the implementation pointer is a fairly verbose smart pointer class that explicitly replicates all methods, and the only advantage it provides over an auto_ptr to an abstract class with a virtual destructor is that it allows to use . instead of -> to access methods.

COM adds new functionality:

• method calls can be marshalled and transported to different execution contexts
• all objects contain a reference counter, which allows sharing of objects between non-cooperating contexts
• runtime dispatch is performed through GUIDs, which allows altering interface definitions without compatibility issues as long as the old GUID is still recognized and a compatibility layer loaded
• objects can be composed of different sub-objects, but pretend to be a larger single object to the caller.
• the common binary interface and restrictions on memory allocation allow calls between code generated with different compilers, and even linked against different implementations of the runtime

The marshalling aspect is the most important one, as the execution context of the callee may be a different, privileged process that provides a system service.