On Wed, Jan 17, 2001 at 08:54:10AM +0100, Valeri Todorov wrote:
> Hello
>
> > > 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.
> Headers are not an issue here. What I am talking about is that things has
> different names in LIB/DLL. I can send you a LIB and HPP file of a simple
> class, with only static memeber, but you will not be able to use (you will
> fail at link time) even with headers available, since I won't tell you which
> compiler to use. But any functions, delclared as extern "C *will* be useful,
> since mangling (AKA decorating) is standard, although unofficial
Um, COM *does* provide a spec for this, because you have to be able to use
COM objects across compiler boundaries. AFAIK this is done as part of the
declaration specification magic. And again AFAIK (get me if i'm wrong) XPCOM
does this as well -- I assume it's folded into NSI_EXPORT or whatever the
declaration magic is for methods that are exported from a DLL ...
But by all means, don't believe me. Go look at the symbol table yourself. MS
used to ship a utility called QuickView (or maybe it came with VC++) that
could look at the symbols a dll provides ...
ari