On Tue, Jan 16, 2001 at 06:35:56PM -0600, Ken Kozman wrote:
> I reread my post in your reply and it was a little harsh, sorry I was
> between meetings and in a bit of a rush (plus I'm a jerk which doesn't help
> matters any... :) )
huh? oh i didn't notice. in any case I'm sure i can defeat you in any
asshole competition ...
> >
> > right. but it should be fine (unless i'm dumber than even i think) to do
> > something like instantiate an object whose methods live in a library
> > compiled by another compiler.
> >
>
> Again I'm not sure if we are talking about the same thing here. If you had a
the conversation makes sense to me. but maybe i'm in the minority here ;)
> library and you had a header to that library which defined a class, say
> CFoo. Then you still do not want to pass CFoo's over interface boundaries
> (whether by value or by reference.) The reason is that although the header
> is the same, the binary structure of that class implementation is compiler
> dependant. Maybe I'm wrong when I say that, I'm not entirely sure how it
on unix there is no magic: the assumption is that one compiler is used to
build everything.
on windows, everything uses the com format. remember, an interface is the
same as any other object to the C++ compiler -- it just happens not to have
any data members. the layout of the data members is guarantee (afaik)
because of C specs on struct layout. so yeah. *any* object you pass around
will be fine, as long as it did the COM magic to make sure it's using COM
layout.
> works with shared libraries on Unix. I think the problem could still be
> there though. I know this was one of the features of interface based
> programming, it frees you from the compilers.
not interface based programming. the com layout itself. for a good
discussion of this, read the first bit of Don Box's "Essential COM". he
derives the reasoning behind COM basically by deriving an object format that
end-runs the intercompiler-compatibility problems for layout and RTTI, then
says "Look, we came up with COM!".
> > > side. So what happens if the side without creates a CString object,
> > > passes it across the interface boundary, and the guy on that side
> > > tries to call GetLength( ) on it?
> >
> > but the headers *are* available ... so it should be deal-withable.
> >
>
> But there is nothing which guarantees a match between the headers for
> CString. I could have compiled one with the version 2.0 headers, and the
> other with the version 3.0 headers. Since interfaces can not change over
> time they do not suffer from this same versioning nightmare. But normal
> classes and headers can and do.
This can happen with interfaces time. What you're describing is a *policy*
not a mechanism. It's COM design policy that internal representations can
change while interfaces should remain constant. I can guarantee you that
mozilla breaks the latter rule often enough :). and if you had different
versioning on the interface header files, it would break your intercompiler
compat as well.
in general tho if you're doing intercompiler stuff, the product is decently
released and you're only using the publicly exported interface headers. even
within mozilla, modules only share relatively stable stuff outside the
module. so it shouldn't be a big deal.
>
> > I think we all agree here :) modulo my abuse of terminology. The real
> > questions are
> > a) does this work with mozilla in practice (worth trying, right? it
> > *should*)
>
> I'm afraid I'm a little lost in this conversation train. If the question of
> whether or not we can build XPCOM components with different compilers is the
> question, then I think the answer is yes. But it is only yes if your
> interfaces only pass the primitive IDL types or other XPIDL interfaces. I
> don't think you can pass pointers or references or values of utility classes
> (which are not just interfaces.) If you do, then things will break. Not just
> cross compiler either, they will break cross version of the internal
> component libraries utilized and such.
"passing an interface" and "passing a pointer" and "passing a reference" are
the *same thing*. interfaces are *not special*.
however, if everyone is playing by the rule that "interfaces are static to
prevent headaches", then to follow this rule the correct thing to do is pass
an IUnknown and query interfaces down to what you need (checking errors all
the way). If you have the guarantee of interface stability, this guarantees
that the object will support the interface you want.
but *all* objects *will* work (in a fundamental "compiler understands the
object format" way) as long as they're declared with the COM declaration
gobbledygood. So the only things that will break in mozilla are any utility
objects that are *not* declared this way. Note that you *don't* have to
implement nsISupports (and therefore there's no overhead penalty for
converting any malingering raw-C++ objects). And this will only work if
everybody's got correct header files.
cheers,
ari
