From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11416 invoked by alias); 11 Oct 2011 00:07:29 -0000 Received: (qmail 11407 invoked by uid 22791); 11 Oct 2011 00:07:27 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-bw0-f47.google.com (HELO mail-bw0-f47.google.com) (209.85.214.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 11 Oct 2011 00:07:12 +0000 Received: by bke11 with SMTP id 11so9719400bke.20 for ; Mon, 10 Oct 2011 17:07:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.76.11 with SMTP id a11mr30514373fak.1.1318291630871; Mon, 10 Oct 2011 17:07:10 -0700 (PDT) Received: by 10.152.20.66 with HTTP; Mon, 10 Oct 2011 17:07:10 -0700 (PDT) In-Reply-To: <20111010222528.GB29806@synopsys.com> References: <59662D5BB74CD84D9FA8E6491ADB51A7DEAE4E3D@US01WXMBX1.internal.synopsys.com> <20111010222528.GB29806@synopsys.com> Date: Tue, 11 Oct 2011 10:53:00 -0000 Message-ID: Subject: Re: Long-term plan for C++98/C++11 incompatibility From: Gabriel Dos Reis To: Joe Buck Cc: James Y Knight , "gcc@gcc.gnu.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes 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/msg00170.txt.bz2 On Mon, Oct 10, 2011 at 5:25 PM, Joe Buck wrote: > 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. =A0The layout for user-defined classes is the same, and PODness has changed from C++98. > code sequences for calls that don't include new features like rvalue > references is the same. =A0Some very important classes from the standard > library are different, and that creates an incompatibility. It is not just class layout. It is also function signatures. > >> The best thing people should do is to take it seriously that that they s= hould >> 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. =A0If 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. By no means am I preventing anybody from solving that problem if they believe that is how their time is best spent. I am offering only a realist= ic assessment. When distros deam g++ support for C++11 sufficiently well advanced that they feel adventurous enough to officially support the experimental support, then I am confident they will do the responsible thing: offer two sets of libraries, as they did in the past when we moved to GCC3. > > I wrote: >> Eventually there would need to be one libstdc++ that programs link again= st and >> run whether they use c++98 or c++11. I would expect there to be restrict= ions, >> 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. =A0They would have to recompile the source cod= e. > > They will need to build their code with the same compiler, yes, and it > won't be binary-compatible with older versions. =A0But as of today, the > templates in libstdc++ expand differently depending on language mode, so > the library is already providing both sets of interfaces. For the record, I am not endorsing this as a recommendation for those interested in C++11 -- I am already stated my recommendation. > > 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 featu= res > internally even when the user has specified c++98 (to get move semantics, > for example). > >