My version of Cary's notes (I just wrote this on my Google+ stream): We had a useful discussion about C++11 ABI issues at the GNU Tools Cauldron (http://gcc.gnu.org/wiki/cauldron2012). The approach will be shaped over time, but the general idea is as follows.
We will modify g++ to support a type attribute indicating the version of the type, as a string. This type attribute will be inherited by any other type that uses it, as a class/struct member or via inheritance. Type attributes will be concatenated as needed. This type attribute will then be used in the mangled name of any function that takes a parameter of a type with an attribute or returns a type with an attribute. The type attribute will also be used in the mangled name of any global variable whose type has an attribute. When this feature is implemented in the compiler, we will be able to change libstdc++ to add attributes to types. In particular, this will permit us to define a new version of std::string with an attribute. Then you will get either the old version of std::string or the new version depending on compiler options or -D options or something. Code that uses the new version of std::string will have mangled names that are different from the code that uses the old version of std::string. It's important to note that these mangled names will be different for uses of the type that are not normally mangled, such as function return types and global variable names. The difference in mangled names means that code compiled using the new std::string will not be able to call code using the old std::string, thus ensuring that such code can not silently fail. This will also mean that it is possible for the same executable process to include code that uses the old std::string and the new std::string, a situation that can arise naturally when a C++ executable dlopens a C++ plugin. This all matters because C++11 mandates a different definition for std::string than the one currently in libstdc++. This approach will make it possible for C++11 and C++98 code to co-exist in the same executable image. Attempts to link them together in ways that can not work will be rejected at link time or (by the dynamic linker) at runtime. This will permit us to keep the same soname for libstdc++, simplifying life for C++ users. We also plan to have a mode in which the compiler emits exact information for all types, functions, and variables in a text file, in such a way that different text files can be merged together. We can then use this to specify the exact libstdc++ ABI, and detect any changes to that ABI. This will again detect changes that are not currently detected by looking only at mangled names and only at instantiated templates. This won't be particularly easy to implement, and doubtless various issues will arise, but I think this will make it possible to transition libstdc++ to c++11 with relatively minimal disruption for users, and, most importantly, without any of the silent failures that were possible in the last libstdc++ transition. Ian
