I discovered this link which exposes Microsoft's hidden agenda. I wrote the webmaster of this site and thanked them for educating us with the facts:
sun.com
BTW, since when does COM force developers to use clean, well-defined interfaces? The only reason you would want to subject yourself to COM is either to support Visual Basic developers or as self-registering DLLs for runtime binding. That's why any third-party controls I buy are C++ classes and not COM objects. There is no justification for using COM over C++ classes from which I can simply and easily derive extensions. Moreover, the interfaces use objects, not just strings and integers. During design, we defined the interface for objects which could be plugged in after installation and we wrapped only those interfaces in COM. Everything else is clean, object-oriented C++ classes with exception handling, multiple threads, ODBC and the rest of it. Stay away from COM unless there is some compelling reason to use it. BTW II, COM is about as slow as it gets when you compare it to a DLL or static C++ class interface. BTW III, using MFC does not produce any extra overhead over ATL if you are already using MFC in the host application, which I am.
|
