[Prev][Next][Index][Thread]

Re: com and gcc question

COM and C++ are two independent object models, though with many 
similarities. COM is designed to be supported 'natively' by an OS, C++ is
designed to be supported by the compiler libraries.

For the one to >>reliably and robustly<< talk to the other, someone will
need to write interface classes - one for COM -> each c++ implementation and
one for each c++ implementation -> COM.

(And no, I'm not volunteering, much as I'd love to!!)
--
guy =:)


----------
>From: Alastair Reid <reid@cs.utah.edu>
>To: Christian Smith <csmith@micromuse.com>
>Cc: Pat Villani <patv@monmouth.com>, University of Utah OS Kit List
<oskit-users@cs.utah.edu>
>Subject: Re: com and gcc question
>Date: Wed, Sep 22, 1999, 9:57 AM
>

>
> Christian Smith <csmith@micromuse.com> writes:
>> Vtables are an abstract concept. You should not depend on their
>> implemntation.
>
> He then goes on to explain how to use structs to generate COM interfaces:
>>  struct {
>>   // This table hopefully should be in a COM compatible
>>   // format. If were going to be pedantic, maybe we should
>>   // just have an array of pointers in here, and use casts
>>   // in the main code.
>>
>>   // Generic COM interface functions.
>>   HRESULT (*QueryInterface)(...);
>>   HRESULT (*AddRef)(...);
>>   HRESULT (*Release)(...);
>>
>>   // Interface specific functions
>>   HRESULT (*Foo)(...);
>>  } * table;
>
> But (as his comment reveals), this still isn't guaranteed to produce a
> valid COM interface because C/C++ doesn't guarantee any particular
> layout for structs - it relies on assumptions which happen to be valid
> on all 32 bit C compilers we know about.
>
> We're making the same "mistake" both when using vtables and when using
> structs of assuming something about the language that isn't
> necessarily true but which may be true for particular compilers.  The
> only difference in this case is that the vtable assumption is often
> false whereas the struct assumption is (AFAIK) always true.
>
>> If I've missed something, give me a shout. I've a feeling theres a
>> problem with this else Microsoft would have implemented it this way
>> in the first place:)
>
> COM is a binary standard with no bias towards any particular language.
> Therefore Microsoft had to specify a particular layout for interfaces
> so that anyone using any implementation of any language would know
> precisely what they had to do to use a COM object.
>
> [This aspect isn't always clear - the first few pages of this paper
> give the clearest explanation I've ever seen of this.  The paper was
> written by people who wanted to use COM from Haskell (a
> research/teaching language which is trying to move into the real
> world) - it was written before the authors worked for Microsoft.
>
>   http://research.microsoft.com/Users/simonpj/Papers/com.ps.gz
>
> ]
>
> Ok, so suppose there's a binary standard out there that you want to
> use and suppose you're free to add extensions to your compiler or to
> tweak its representations a little so that it's easy to generate
> things that satisfy that binary standard.  What are you going to do?
> You tweak it, of course - with the result that code that exploits your
> tweak isn't as portable.  Here in planet OSKit, we certainly exploit
> a few gcc-ish features.  In fact, our code isn't even portable between
> recent versions of gcc.
>
> [I'd like to jump on the conspiracy theory bandwagon and say that
> Microsoft adding tweaks to their compiler was just them trying to lock
> people into their compiler but, having written a bunch of compilers
> myself, I know that it's a very hard job to keep the languages
> accepted by just two compilers in step even when you have perfect
> communication between the developers of both compilers.  An extensions
> which is just an afternoon hack for one compiler might require a month
> of work for the other one; priorities may be very different; etc.
> Moving into a competitive environment makes compatibility harder to
> achieve but the pressures are already hard to resist in a friendly
> environment.]
>
> --
> Alastair Reid        reid@cs.utah.edu        http://www2.cs.utah.edu/~reid/