This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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. After I noted that,
paolo and redi then told me it was in fact already broken long before, due
to numerous other ODR violations in libstdc++ when compiled in the
different modes. I just hadn't noticed. D'oh.

So, it's actually rather tricky to correctly use --std=c++0x. While it
*looks* like you can just compile your own code with that flag (it appears
to work), it seems that it doesn't actually work, and is expected to work
less and less as time goes on. (Presumably std::string will be made
non-refcounting soon to be C++11-conformant, breaking interoperability
much more.)

I guess to start, it would have been nice if there was a big warning on
http://gcc.gnu.org/projects/cxx0x.html telling me not to use c++0x mode
unless there are no objects compiled with c++98 linked into the same
executable. I know I'm not the only one who didn't realize how broken it
was to do that. I also suspect there's plenty of other people who still
don't know that, and will be unpleasantly surprised by mysterious
seg-faults soon.

I completely understand that the current support in GCC is still
experimental, and I should expect nothing from it. But what I'd really
like to have a handle on is what things are supposed to look like when
C++11 support is no longer experimental. What's the planned final state of
affairs?

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

* 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?

* 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?

* 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?

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.)

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.


Thanks for any insight! This seems to be a lot more complex than I naively
thought the transition was going to be.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]