Re: Long-term plan for C++98/C++11 incompatibility

[Jonathan Wakely <jwakely.gcc@gmail.com>]

On 7 October 2011 23:24, James Y Knight wrote:
> I just noted at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49561 (due to
> std::list), that it's currently impossible to use any C++11-compiled code
> in a program which also uses any C++98 code, even if the two pieces of
> code never actually touch each other or share objects.

I think that's overstating the case.  There are some incompatiblities
in the standard library, but there's no problem linking e.g.

int f() { return 0; }

and

int f();
int g() { return f(); }

So it's not true that it's "impossible" to link "any" code using the two modes.

> (Presumably std::string will be made
> non-refcounting soon to be C++11-conformant, breaking interoperability
> much more.)

Yes, std::string will be made non-reference counting at some point,
but as a non-reference-counted string is valid in C++98 as well, one
option would be to switch to a non-ref-counted string for both
-std=c++98 and -std=c++11 modes.  I'm not saying that's what will
happen, but it could be.  The same is true of an O(1)
std::list::size().  For the next major ABI change we could switch
c++98 mode to use a non-ref-counted string and O(1) list::size.
Currently we aren't changing string or list in c++98 mode, because
that would break code. But we are changing it for c++0x mode, because
people want the C++11 semantics.  Breaking things for people using the
experimental c++0x mode is less catastrophic, as noone is forced to
use that mode and noone has years of existing code relying on its
semantics.

> * Will STL-using

Standard Library, not STL, please.

> code compiled with -std=c++98 and -std=c++11 remain
> incompatible forever, or only until it's no longer experimental?

I don't think it's been settled, but as I said above, there are ways
to change both modes at once. Currently we can't do that
> * If so, will version namespaces be used to give c++98 std::* and c++11
> std::* non-conflicting symbols eventually, so that at least the same
> program can load two shared libs that only use the STL internally and not
> in their interfaces?

Maybe.  Or symbol versioning.

> * For that matter, are the c++98 and c++11 languages even link-compatible
> without STL? Is the incompatibility only due to the #ifdefs in the STL
> headers or is it more fundamental than that?

The basic ABI hasn't changed, the differences are because the standard
library code is different in c++0x mode (e.g. functions take different
parameter types), not because the compiler does different things when
compiling it.

> * How are binary linux distributions expected to support c++11 programs?
> (in that they'll need to eventually provide shared libraries to link
> against which a c++11-compiled binary can use).
>
> It seems to me that it can't be done like previous ABI transitions (just
> recompile the whole world with the new ABI, boom done), since C++11 is not
> source compatible with c++98.
>
> So should a distro compile two copies of all C++ libraries, one for C++11
> and one for C++98? Then, I suppose people will have to change e.g.
> "-lPocoNet" to "-lPocoNetCXX11" in their link lines? Or maybe ld/gcc will
> be modified to automatically choose a different library search path, based
> on the compilation mode?

Having separate libs is a posibility, but it might make more sense to
have a single lib with versioned symbols.

> Or will there be a giant flag day after most projects compile can compile
> in both c++11 and c++98, where c++98 support is removed, and everything is
> compiled in c++11 from then on? (but then, how would we get there: all
> developers would have to compile their entire dependent set of libraries
> from scratch themselves to test their code, I guess.)

Not going to happen.

> I hope the experts here have a better idea of how this is all going to
> work that I do. IMO it would be best if if the new ABI could be enabled
> separately from the C++11 language, so that you *could* compile everything
> with the new ABI, and have c++98 and c++11 code interoperate. But I have
> no clue if that's even remotely feasible.

The current ABI changes are caused by C++11 requirements on the
library, so I don't see how that's possible.