This is the mail archive of the
mailing list for the libstdc++ project.
(not) breaking the ABI
- From: chris jefferson <caj at cs dot york dot ac dot uk>
- To: libstdc++ <libstdc++ at gcc dot gnu dot org>
- Date: Wed, 25 May 2005 14:28:43 +0100
- Subject: (not) breaking the ABI
After a brief discussion on IRC, and recent discussion on the main gcc
mailing list, I discovered it is perhaps harder to break the ABI that I
thought it was :)
As far as I've been able to find out, things we go into so_6 cannot:
a) turn a POD into a non-POD
b) add or remove virtual member functions of classes/structs
c) add or remove data members of classes
d) Change a function so does something fundamentally different, as you
don't know which the linker will choose to pull in (you can of course
just give your new function a new signiture and delete the old one).
Out of interest, is that it? I tried looking around for a specific guide
to what breaks ABIs and while I could find some good guides for C, I
couldn't find one for C++.