From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17399 invoked by alias); 7 Nov 2002 00:47:22 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 17380 invoked from network); 7 Nov 2002 00:47:21 -0000 Received: from unknown (HELO localhost.localdomain) (66.60.148.227) by sources.redhat.com with SMTP; 7 Nov 2002 00:47:21 -0000 Received: from warlock.codesourcery.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.11.6/8.11.6) with ESMTP id gA70ind10445; Wed, 6 Nov 2002 16:44:49 -0800 Date: Wed, 06 Nov 2002 16:47:00 -0000 From: Mark Mitchell To: Richard Henderson cc: Jakub Jelinek , Aldy Hernandez , "gcc-patches@gcc.gnu.org" , "jason@redhat.com" Subject: Re: [basic-improvements] try/finally support for c/c++ - more tests Message-ID: <38180000.1036629889@warlock.codesourcery.com> In-Reply-To: <20021107000307.GQ22215@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SW-Source: 2002-11/txt/msg00386.txt.bz2 > See elsewhere about resistance compiling libc with a c++ compiler. I know there's resistance, but frankly I think that's just predjudice. Compile the bits you need C++ features for in C++. Avoid stuff that seems fragile, like virtual bases/virtual functions etc; just use try/catch and/or destructors if that's all you want. The functionality you need has been stable for ages and ages. I feel strongly that we should not try to bring C++ features into C, just to avoid having to compile some stuff in libc with G++. Especially as similar features may eventually go into ISO C with subtly different semantics. > The main problem is that you simply cannot implement cleanups with > a few calls to a runtime library. There are data structures that > the compiler must set up related to how it generated code. > >> If we do want to check these patches in, the semantics should be given >> in terms of translation to (1) above. I should have said (1) or (2). I'm comfortable with either formulation, and you're right that they are subtly different. If we do (2), we have to word it cleverly; a literal substitution wouldn't work because local variables wouldn't be available in S::~S. > Further, try/catch/rethrow does not express what happens when > you use goto/break/continue/return to leave the try block. True. I don't want to distract us by getting into that; I'm happy to go with the translation (2) which seems to be what you prefer, if we decide we absolutely must introduce this feature. I, however, am far from convinced. -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com