From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16712 invoked by alias); 24 Jun 2014 18:10:38 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 16700 invoked by uid 89); 24 Jun 2014 18:10:38 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: smtp.mozilla.org Received: from mx2.corp.phx1.mozilla.com (HELO smtp.mozilla.org) (63.245.216.70) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 24 Jun 2014 18:10:36 +0000 Received: from tsaunders-iceball.corp.tor1.mozilla.com (unknown [64.213.68.131]) (Authenticated sender: tsaunders@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id F1DBBF2711; Tue, 24 Jun 2014 11:10:33 -0700 (PDT) Date: Tue, 24 Jun 2014 18:10:00 -0000 From: Trevor Saunders To: Tom Tromey Cc: Jeff Law , gcc-patches@gcc.gnu.org Subject: Re: [PATCH 5/5] add libcc1 Message-ID: <20140624181013.GA24913@tsaunders-iceball.corp.tor1.mozilla.com> References: <1400254001-12038-1-git-send-email-tromey@redhat.com> <87oayx4l0x.fsf@fleche.redhat.com> <87bntobp1f.fsf@fleche.redhat.com> <20140620031058.GA12633@tsaunders-iceball.corp.tor1.mozilla.com> <87vbrv8uje.fsf@fleche.redhat.com> <53A87B75.4090705@redhat.com> <20140624031231.GA1815@tsaunders-iceball.corp.tor1.mozilla.com> <87mwd22pvd.fsf@fleche.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87mwd22pvd.fsf@fleche.redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-IsSubscribed: yes X-SW-Source: 2014-06/txt/msg01919.txt.bz2 On Tue, Jun 24, 2014 at 11:12:38AM -0600, Tom Tromey wrote: > Trevor> hrm, I know basically nothing about the upcoming changes, but I would > Trevor> have expected linking c++03 code against c++11 code would be fine > Trevor> especially when the interface doesn't involve any stl. > > https://gcc.gnu.org/wiki/Cxx11AbiCompatibility > > This warns against mixing with C++98, which seems to be how GCC is > built. > > While I agree that in this specific case it is probably safe, since gcc > in general isn't a heavy user of libstdc++, I think it's reasonable to > simply follow gcc. This is safer in case gcc changes; and the benefit yeah, I'm not disagreeing at this point. > from C++11 in libcc1 is modest, especially when you consider the extra > template magic we'd need in order to actually use variadic templates for > the RPC stuff. It would get a little more than that, actually deleting the copy ctors and stuff you don't want people to call is one thing that comes to mind. > > Trevor> Well, we build everything or at least everything I've seen with > Trevor> -fno-exceptions, so if something does throw we'll just crash right? > Trevor> istm we certainly write code calling the throwing new with that > Trevor> expectation. > > Gcc's coding conventions say that code ought to be exception-safe in > case exceptions are used in the future. Search for "Exceptions" here: > > https://gcc.gnu.org/wiki/CppConventions I think that's a good idea in general, mostly because it results in simpler code, I think the idea gcc will be exception safe in a reasonable amount of time is a bit of a pipe dream. > > I think retaining the std::nothrow is safer in view of this, and doesn't > cause any problems. I think in general trying to handle allocator failure is a waste of time, that is all the places we call the throwing new today we'd want to keep doing that in a world with exceptions and just let the exception kill us. So assuming you actually want to handle allocator failure in this particular case for some reason that seems reasonable. Trev > > Tom