Thread: Recommended Book on COM :: C++

  1. #1
    Registered User
    Join Date
    Nov 2001
    Posts
    1,348

    Recommended Book on COM :: C++

    Hi.

    Two weeks ago I posted a similar message about recommended advanced C++ books. An overwhelming number of responses mentioned Scott Meyers' Effective series including STL, Modern C++ Design: Generic Programming and Design Patterns Applied
    by Andrei Alexandrescu, and Design Patterns.

    I decided on Scott Meyer's Effective STL and Modern C++ Design: Generic Programming and Design Patterns Applied
    by Andrei Alexandrescu. I definitely agree those books are exceptional in terns of advanced techniques and design patterns. I learned more from those books have from all previous C++ books I owned.

    Now I am ready to move ahead and learn more specific software design, COM. I believe COM should be the next concept to look into because as windows applications become more integrated, COM will be even more popular and useful in the future.

    I have heard about ATL and know that ATL is to COM and MFC is to Win32 API. Nonetheless, I do not know how ATL relates to C++.

    What do you recommend as the best book on COM concept and implementation using C++?

    Thanks,
    Kuphryn

  2. #2
    Code Monkey Davros's Avatar
    Join Date
    Jun 2002
    Posts
    812
    Forget COM for the following reasons:

    1. COM is no good. IMHO.

    2. There are no good books on COM. There are only advertising brochures which masquerade as books. IMHO.

    3. Microsoft has abandoned COM in the .NET architecture, supporting it only for backward compatibility. Probably because of reason 1.
    Last edited by Davros; 10-19-2002 at 04:52 PM.
    OS: Windows XP
    Compilers: MinGW (Code::Blocks), BCB 5

    BigAngryDog.com

  3. #3
    Registered User
    Join Date
    Nov 2001
    Posts
    1,348
    Okay. Thanks.

    Are you serious?

    Kuphryn

  4. #4
    Code Monkey Davros's Avatar
    Join Date
    Jun 2002
    Posts
    812
    Yep. I'm serious. While it may be obvious that I'm cynical of COM, the explanation below is honest & I hope it will be helpful.

    I looked into COM a couple of years ago & bought a whole load of expensive books. None of them would tell what I wanted to know, but were filled with ad-speak marketing lingo. Over a period of time I figured out what COM was really all about.

    At the end of the day, COM is about exporting objects from binaries, so that they can be used in other modules and/or applications. Kind of like an 'objectised' DLL.

    While you can export objects directly from a DLL, this is danger prone because the binary layout expected by the client application must match that used in the DLL. This is often difficult to maintain.

    For example, you have a DLL which packages some objects. This DLL is loaded by client application. Sometime later, the author of the DLL spots a bug & decides to fix, while keeping the public class interface the same. To fix the bug he finds he must add an extra private data item in the class and does so. The DLL is recompiled & linked to the client application. What happens? BANG!. The class footprint no longer matches that described in the header files used by the application, because those header files also describe the private data & functions of the class (they must do so).

    A long standing approach to overcoming this is to use pure virtual base class interface definitions which use only pure virtual methods. This is totally standard and not proprietry to M$. A detailed explanation of this is too much for this reply, but in short it allows programmers to change the backend in DLLs, while maintaining interface & binary compatibility with clients.

    In fact, this is COM under the hood! But I've found very little in the way of literature which explains this. Instead the stuff I've read seems to studiously avoid telling anyone what's really going on. We are simply led to believe Microsoft have invented all the magic & we should be really impressed.

    Another important reason for exporting objects from binaries is so that they can used in applications built with different compilers. The problem here is that different compilers use different memory management. Therefore a class definition in a header file compiled into an application built with BCB, is not going to match the corresponding binary footprint of the object contained within a DLL compiled with VC++. However, while (normal) non-virtual class definitions are incompatible, in Windows different compilers do tend to be compatible where object virtual tables are concerned. This compatibility is maintained precisely so that non-m$ and VB compilers may make use of COM.

    An additional feature of COM is that each DLL contains only one object. M$ doesn't call their binary files DLLs of course, they give them a different extension to make us believe they're something else. In COM, objects & the corresponding DLL filenames are linked via the Windows registry, so that when an application says 'I want a new instance of FOO object', Windows can find which DLL contains FOO. Ever wondered why many Windows applications are so slow to load and prone to becoming unstable for no apparent reason?

    If you're interested in COM, I suggest that you learn about virtual methods and base class interfaces first. I've attached a short discussion I wrote a while back on using inheritance* in base classes. In it is a link to some Borland introductions about pure virtual base classes & compability issues. It's interesting stuff & well worth a read.

    Oh why am I saying M$ has abandoned COM? The simple answer is that it isn't needed anymore. The MSIL adds another layer of isolation to take care of such compatibility issues.

    *COM doesn't support inheritance because COM was designed to be compatible with VB.
    Last edited by Davros; 10-19-2002 at 05:59 PM.
    OS: Windows XP
    Compilers: MinGW (Code::Blocks), BCB 5

    BigAngryDog.com

  5. #5
    Registered User
    Join Date
    Nov 2001
    Posts
    1,348
    Very interesting. Thanks.

    I did not know that Microsoft designed COM for object sharing among C++ and Visual Basic programs and DLL.

    If COM is not advanced Windows program, what does everyone think is and will be advanced Windows programming?

    Thanks again,
    Kuphryn

  6. #6
    Guest Sebastiani's Avatar
    Join Date
    Aug 2001
    Location
    Waterloo, Texas
    Posts
    5,708
    That was very insightful, Davros.
    Code:
    #include <cmath>
    #include <complex>
    bool euler_flip(bool value)
    {
        return std::pow
        (
            std::complex<float>(std::exp(1.0)), 
            std::complex<float>(0, 1) 
            * std::complex<float>(std::atan(1.0)
            *(1 << (value + 2)))
        ).real() < 0;
    }

  7. #7
    It's full of stars adrianxw's Avatar
    Join Date
    Aug 2001
    Posts
    4,829
    COM+ Programming from the Ground Up by Mark Michaelis is a book that springs to mind - not a book for beginners though, it starts a bit deep and gets deeper.

    BTW, Borland has a vested interest in trashing COM as they are heavily involved with the rival CORBA group. In my opinion, neither is perfect, but both work to a greater or lesser extent. The original COM was pretty naff, but COM+ sorted out most of the worst of it. CORBA was always an elegent solution, but the presence of the ORB broker software added overhead, and cost - most ORB software is expensive.

    I do not believe either will survive in the long term.
    Wave upon wave of demented avengers march cheerfully out of obscurity unto the dream.

  8. #8
    Code Monkey Davros's Avatar
    Join Date
    Jun 2002
    Posts
    812
    I believe COM & CORBA are not equivalent. COM is simply an object packaging model, while CORBA is a distributed object model. I understand DCOM to be the M$ equivalent to CORBA.

    I think M$ have made the whole issue very confusing by treating COM/DCOM as if they are inseperable. When I started with COM, I found it really confusing (I am still confused). All I wanted to do was to export classes from a DLL, not to have my app relient on a server process to dish out objects. I'm still not really happy with calling a DLL the server & an application the client.

    >I do not believe either will survive in the long term.

    I agree with you.

  9. #9
    pronounced 'fib' FillYourBrain's Avatar
    Join Date
    Aug 2002
    Posts
    2,297
    Davros, while I share your distaste for the way COM works and how confusing it is I don't see how they will completely abandon it.

    IE plugins for instance. They are ActiveX which is COM. Can .NET replace those? If so, is there a plan to?

    I for one have studied COM through books like "Essential COM" which gets into great detail. Even if you don't use COM per se, you can use many of these concepts in this book for cross-dll objects. That's usually what I do. Interface pointers across dll boundaries are wonderful for versioning and other issues.
    "You are stupid! You are stupid! Oh, and don't forget, you are STUPID!" - Dexter

  10. #10
    Code Monkey Davros's Avatar
    Join Date
    Jun 2002
    Posts
    812
    >They are ActiveX which is COM. Can .NET replace those?

    I think that's the long term plan. But not by tomorrow.

    Thanks for the reply. I'll have a look at the book you suggested.
    OS: Windows XP
    Compilers: MinGW (Code::Blocks), BCB 5

    BigAngryDog.com

  11. #11
    Registered User
    Join Date
    Oct 2002
    Posts
    6

    Post

    Davros: The book I'd recommend if you really want to get an in depth understanding of COM is "Inside COM" by Dale Rogerson.

    .Net is not exactly a replacement for COM it is, among other things, the next iteration of COM (or Automation, and technically COM+ came after COM so I suppose .Net would be the next iteration of COM+). The biggest selling point of .Net is that it adds machine independence (like Java). However, unlike Java the .Net platform compiles the code on the target machine the first time it's run thus avoiding the overhead imposed by an interpreter.

    Having a good understanding of COM will help anyone looking to become familiar with .Net.

  12. #12
    It's full of stars adrianxw's Avatar
    Join Date
    Aug 2001
    Posts
    4,829
    >>> I understand DCOM to be the M$ equivalent to CORBA.

    True, however, COM+ and DCOM are pretty inseperable. I believe MS have moved quietly away from DCOM, but then, how many CORBA jobs do you see advertised.

    There are other solutions, and I think people are using their own solutions as well as the named players.
    Wave upon wave of demented avengers march cheerfully out of obscurity unto the dream.

  13. #13
    Registered User
    Join Date
    Nov 2001
    Posts
    1,348
    In what field of software design do software engineers utilize COM most often?

    What are the differences betwee COM, DCOM, and COM++? Lastly, do you have to know COM to learn latter two revisions?

    Kuphryn

  14. #14
    Guest Sebastiani's Avatar
    Join Date
    Aug 2001
    Location
    Waterloo, Texas
    Posts
    5,708
    Any field. Use COM whenever you want to use premade objects/services using that interface.
    Code:
    #include <cmath>
    #include <complex>
    bool euler_flip(bool value)
    {
        return std::pow
        (
            std::complex<float>(std::exp(1.0)), 
            std::complex<float>(0, 1) 
            * std::complex<float>(std::atan(1.0)
            *(1 << (value + 2)))
        ).real() < 0;
    }

  15. #15
    It's full of stars adrianxw's Avatar
    Join Date
    Aug 2001
    Posts
    4,829
    Yes, any field where the need arises.

    COM was MS's first attempt - it was decidedly shaky but it did work. It did not become widely used because it was so cumbersome. COM+ addressed a lot of the shortcomings, and DCOM is a "distributed" version of COM+.

    I would not consider learning COM. If you need the technology, go straight to COM+ - it is what is used today. As usual, there are some compatibility issues, so if you are working with a COM system then you may be better off staying with COM, but otherwise, forget it.
    Wave upon wave of demented avengers march cheerfully out of obscurity unto the dream.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Recommended C#/.NET Book
    By kuphryn in forum C# Programming
    Replies: 4
    Last Post: 04-23-2004, 09:21 AM
  2. Books on C and C++
    By kermi3 in forum A Brief History of Cprogramming.com
    Replies: 16
    Last Post: 10-28-2002, 04:18 PM
  3. Recommended book for DirectX?
    By Dual-Catfish in forum Game Programming
    Replies: 3
    Last Post: 05-26-2002, 10:23 PM
  4. any recommended exercise book for C++?
    By gogo in forum C++ Programming
    Replies: 5
    Last Post: 11-07-2001, 04:44 PM