Bradley Baetz wrote:
> > I don't think that we were talking about vtable layout
> > here. My next sentence was "...that most, if not all,
> > components that I have looked at do import something
> > from xpcom."
>
> We're talking about both. The name mangling only affects
> non extern "C" stuff, but see bug 143771 (for example).
Of course. It's been a while since I last worked in the Mozilla code
base, and a goal at the time was the possibility of making component
modules not require linking to anything, only acting on interfaces
received when loaded by the main application.
I thought that the string classes were all defined in the header files
and thus did not have any link requirements, but it seems that there are
"other" issues involved.
But as Bradley said, the vtable stuff is even more important, since it
affects the root of XPCOM.
> > > A number of compilers have options to make virtual
> > > method tables follow the Microsoft COM layout (which
> > > is documented in the COM Specification), so I suppose
> > > that Mozilla should use these options as much as
> > > possible (it is usually an attribute that you give to
> > > a parent-less class and which is inherited).
> >
> > Is there a option for this in gcc? bbaetz?
>
> I don't think so, but I really haven't looked.
>
> If you do that, though, then won't every app which uses
> mozilla have to do that? What if that app wants to use
> another c++ library with the standard ABI, then? Like
> nautilas, for example? IMHO, we don't want to go there,
> even if it is possible.
The way to use this feature of gcc is via an attribute, like this:
class __attribute__((com_interface)) nsISupports {
...
};
This attribute is automatically inherited, so you do not need to declare
all classes with it. Apparently that gcc 3 and up has the COM layout by
default though, but this will make sure.
Interestingly, it also makes pre-3.0 gcc compatible with 3.0 and up,
vtable-wise (my "XPLC" project (used to be called "XPCOM-Lite") only
uses a few extern "C" functions and everything else is done through
interfaces).
Since this is in the source code itself, there is no problem using it,
as other programs won't have to do anything at all.
This attribute can be used through a macro (I think there is already
something similar on Mac, by the way) that would be defined by an
autoconf test. Leaving the macro empty would give regular behavior.
http://gcc.gnu.org/ml/gcc-bugs/1999-08n/msg01215.html
http://gcc.gnu.org/ml/gcc-bugs/2001-03/msg00824.html
--
Pierre Phaneuf
http://advogato.org/person/pphaneuf/
