Bradley Baetz wrote: > > 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. > > The string lib is statically linked, I think.
So it's semi-ok, as long as the memory layout of a string object stays binary compatible. > > 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. > > Ah, but our Official Compiler is egcs-1.1.2. Which means > that anything we do has to work on that, or we have to > upgrade the compiler, which brings us back to where we > started. I'm pretty sure that it works on that. What I'm saying is that once you get to gcc 3 and up, you won't need it anymore. In fact, using it might enable components compiled with gcc 3 to interoperate with a Mozilla compiled with the older gcc, or the reverse! On gcc 3, it gives a warning about having no effect, which is true. On older versions, it actually does something (make the vtable layout compatible with gcc 3, which happens to be COM-compliant). > > 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. > > ... except be compiled with gcc, and possibly specific > versions of gcc. Yes, but that's exactly where we're at today! But with this, it'll be interoperable between more versions of gcc, and *possibly* other compilers that currently don't work (if they are using COM-compliant vtable layout)! This can only *improve* things! You set up an autoconf test to detect whether this attribute is supported by the compiler, and if it is, we use it. > > http://gcc.gnu.org/ml/gcc-bugs/1999-08n/msg01215.html > > This says that virtual dtors aren't supported in > com_interface stuff, and a class is com_interface if any > of its parents are. That implies that anything which > inherits off nsISupports couldn't use a virtual destructor. > Since mozilla uses virtual destructors in that case in > several places like this, that implies that we couldn't > use it. This guy is saying something along the lines of "I don't actually know anything about this, but I suppose it might be doing any of the following". Hardly proof. Here, to save you some time, I actually TRIED it: pp@snoopy:~> cat foo.cc #include <stdio.h> class __attribute__((com_interface)) Foo { public: virtual void doFoo() = 0; }; class Bar: public Foo { public: Bar() { printf("Bar's constructor\n"); } virtual void doFoo() { printf("Bar is doing Foo\n"); } virtual ~Bar() { printf("Bar's virtual destructor\n"); } }; int main() { Foo* foo = new Bar; foo->doFoo(); delete foo; return 0; } pp@snoopy:~> g++ -Wall -pedantic -o foo foo.cc pp@snoopy:~> ./foo Bar's constructor Bar is doing Foo pp@snoopy:~> gcc -v Reading specs from /usr/lib/gcc-lib/i486-suse-linux/2.95.3/specs gcc version 2.95.3 20010315 (SuSE) pp@snoopy:~> There you go, virtual destructor and all. By the way, using a virtual destructor in a component is on the verge of being nuts. You better damn know what you're doing when you do that! I know it's actually safe most of the time, because objects delete themselves, and they're the one adding the virtual destructor, but for precisely this reason, it doesn't make any sense to use a virtual destructor (they *know* which destructor to call!). Worse, if someone derives them and overrides the destructor, the effects are non-obvious, depending on the implementation of nsISupports::Release. > > http://gcc.gnu.org/ml/gcc-bugs/2001-03/msg00824.html > > > > and this says that this undocumented attribute is uneeded > and deprecated, and will be removed. Not something we want > to be relying on... Actually, it's okay, because it's unneeded and deprecated and will be removed in the FUTURE, when gcc's ABI is COM-compliant by default! You won't need it then, so there's nothing to worry about! I'll repeat: just use it if it's there, if it's not then we're as bad are we are today. > Note that one of the reasons I asked dougt to document this > was because egcs is already 4 years old, and one of the > reasons that we don't upgrade (new libstdc++ isn't on older > systems) may soon start working in the reverse direction > - how long before the old egcs compat libs are no longer > installed by default on linux systems? Not to mention that > large perf improvement we get. Try that little code snippet I put in this message and tell me if it works with egcs. I'd like to know anyway. -- Pierre Phaneuf http://advogato.org/person/pphaneuf/
