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... :) )
>
> 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.
>
> it's clearly bad style to try to delete pre-instantiated objects you
> received from some library somewhere; the code that created the object
> should clean it up.
>
Again I'm not sure if we are talking about the same thing here. If you had a
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
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.
> > anything. What's worse, the pointers or references to the classes you
are
> > passing back and forth could have different declared implementations on
both
> > sides of the interface. CString (as an example) on one side could have a
> > method GetLength( ), and not have it in the header definition on the
other
> > 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.
> 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.
I'm getting the feeling that I'm not making a whole lot of sense here. Did I
help clarify anything?
