On Fri, Oct 07, 2011 at 07:35:17PM -0700, Gabriel Dos Reis wrote: > C++11 is essentially binary incompatible with C++98.
Only partially. The layout for user-defined classes is the same, and code sequences for calls that don't include new features like rvalue references is the same. Some very important classes from the standard library are different, and that creates an incompatibility. > The best thing people should do is to take it seriously that that they should > not attempt to mix or play loose. Unfortunately, distros aren't going to start shipping two versions of every C++ library, so people are going to have to solve the problem that you are saying should not be solved, or at least determine which cases are problems and which aren't. If common libraries are all c++98-only this will slow the adoption of c++11: forcing a flag day when this is not necessary is probably not the right thing to do. I wrote: > Eventually there would need to be one libstdc++ that programs link against and > run whether they use c++98 or c++11. I would expect there to be restrictions, > but it's a problem that eventually needs to be tackled. Gaby writes: > My opinion is that it would an exercise in futility, frustration, and > possibly deception to try to make people believe that there are sets of > simple rules they can follow to mix their C++98 binaries with fully > compatible C++11 library. They would have to recompile the source code. They will need to build their code with the same compiler, yes, and it won't be binary-compatible with older versions. But as of today, the templates in libstdc++ expand differently depending on language mode, so the library is already providing both sets of interfaces. A bump to libstdc++ major version number could be made that ensures, for example, that std::string satisfies the requirements of both languages. It's also possible that the code in the standard library uses c++11 features internally even when the user has specified c++98 (to get move semantics, for example).
