From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11895 invoked by alias); 7 Nov 2002 17:53:40 -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 11863 invoked from network); 7 Nov 2002 17:53:39 -0000 Received: from unknown (HELO localhost.localdomain) (66.60.148.227) by sources.redhat.com with SMTP; 7 Nov 2002 17:53:39 -0000 Received: from warlock.codesourcery.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.11.6/8.11.6) with ESMTP id gA7Hp3J20074; Thu, 7 Nov 2002 09:51:03 -0800 Date: Thu, 07 Nov 2002 09:53:00 -0000 From: Mark Mitchell To: Daniel Jacobowitz cc: Michael Matz , Zack Weinberg , Richard Henderson , 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: <54640000.1036691463@warlock.codesourcery.com> In-Reply-To: <20021107172003.GA27338@nevyn.them.org> 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/msg00474.txt.bz2 > It is when they're written in gnu99. It's also a royal pain to require > a C++ compiler when building glibc; bootstrapping gets harder every > day... Well, you want C++ features, you need a C++ compiler. :-) I'd rather see ISO C99 extensions getting added to G++ than features that don't even exist in C++ getting added to GCC. > Then you require that all pthread_cleanup_push's which need to > be unwound properly be written in C++ source files. Precisely. I think that if you want exception-handling, you should use a language that has that feature. (Otherwise, I want to add Prolog unification and ML type inference to GNU C. :-)) And, if we really, really want exceptions in C, we should pick an existing, standardized model from the C family of languages -- namely the model in C++. Add try/catch, not try/finally. Or, perhaps better, and taking into account RTH's comments, add destructors. -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com