There seem to be two areas of concern with compatibility between the
C++98 and C++11 ABIs:
1) Changes to member function return types, as with std::complex. For
these, the two functions could coexist except that they are mangled the
same way. So I propose that we introduce a mechanism to change the
mangled name of a member function. Unlike with attribute ((alias)), the
declared name would only be visible at the source level, not in the
assembly output.
My inclination is to just have a single declaration and have an
attribute to change its name for linkage purposes.
In the passed we have discussed using inline namespaces to do this sort
of renaming, but that doesn't help with individual member functions
within a class, like the situation in std::complex.
2) Object layout changes to std::list and std::basic_string. For these
types, there is no way to both retain backward compatibility with older
C++98 code and conform to the C++11 standard. The best we can hope for
is to allow old code to coexist with new code so long as they don't try
to touch the same string/list objects.
As above, one solution to this would be to change the linkage name of
the new versions so that they don't clash with the old versions. But
that isn't enough in this case, as it wouldn't affect the linkage name
of a class like
struct Wrap { std::string s; };
so we would need some way to cause the name decoration to propagate to
other containing/derived classes.
It seems that ELF symbol versioning could be useful for this purpose.
If we were to extend the visibility attribute to also handle symbol
versions, that could handle a lot of issues. If Wrap uses the GLIBCXX_4
version of string, then Wrap would also be marked with the GLIBCXX_4
version, and any functions that deal with Wrap would be marked with that
version, and so on.
I'm not familiar enough with the intricacies of ELF versioning to be
confident that this would work; is anyone else? In particular I'm not
sure how the interaction of versioned and non-versioned code will work.
Jason
