From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6303 invoked by alias); 7 Oct 2011 22:24:28 -0000 Received: (qmail 6295 invoked by uid 22791); 7 Oct 2011 22:24:27 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from TMRC.MIT.EDU (HELO torpor.static.net) (18.150.1.81) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 07 Oct 2011 22:24:12 +0000 Received: from localhost ([127.0.0.1] helo=fuhm.net) by torpor.static.net with esmtp (Exim 4.72) (envelope-from ) id 1RCIpv-0003a0-KE for gcc@gcc.gnu.org; Fri, 07 Oct 2011 18:24:11 -0400 Received: from 74.125.59.113 (SquirrelMail authenticated user jknight) by fuhm.net with HTTP; Fri, 7 Oct 2011 18:24:11 -0400 Message-ID: Date: Fri, 07 Oct 2011 23:44:00 -0000 Subject: Long-term plan for C++98/C++11 incompatibility From: "James Y Knight" To: gcc@gcc.gnu.org User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: 8bit Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2011-10/txt/msg00116.txt.bz2 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.