From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10410 invoked by alias); 25 Mar 2003 21:57:59 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 10398 invoked from network); 25 Mar 2003 21:57:58 -0000 Received: from unknown (HELO mail.cs.umn.edu) (128.101.36.202) by sources.redhat.com with SMTP; 25 Mar 2003 21:57:58 -0000 Received: from bose.cs.umn.edu (bose.cs.umn.edu [128.101.35.195]) by mail.cs.umn.edu (Postfix) with ESMTP id 12EDC11311; Tue, 25 Mar 2003 15:57:58 -0600 (CST) Received: by bose.cs.umn.edu (Postfix, from userid 818) id 9D541326F; Tue, 25 Mar 2003 15:57:53 -0600 (CST) To: Zack Weinberg Cc: "Kaveh R. Ghazi" , mark@codesourcery.com, gcc@gcc.gnu.org, gdr@integrable-solutions.net Subject: Re: Converting to ISO C89 From: Raja R Harinath Date: Tue, 25 Mar 2003 22:13:00 -0000 In-Reply-To: <873clbi0p6.fsf@egil.codesourcery.com> (Zack Weinberg's message of "Tue, 25 Mar 2003 13:41:09 -0800") Message-ID: User-Agent: Gnus/5.090017 (Oort Gnus v0.17) Emacs/21.3.50 (gnu/linux) References: <200303250642.h2P6gZ4r025932@doubledemon.codesourcery.com> <1048612019.25895.7.camel@doubledemon.codesourcery.com> <200303251752.MAA08671@caip.rutgers.edu> <873clbi0p6.fsf@egil.codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-03/txt/msg01577.txt.bz2 Hi, Zack Weinberg writes: > Raja R Harinath writes: > >> Hopefully the ISO C89 changes also make the source C++-safe. > > It will not. There is extensive use of identifiers which are C++ > keywords, such as 'class' and 'delete'. I do not think your > suggestion is useful enough to warrant changing all of these > identifiers. Fair enough. > What might be useful is an optional mode for the C compiler in which > function names get mangled as they would be in C++. That would have > the effect of type-checking procedure calls across translation units > at link time. To avoid mangling calls into libc it would have to be > switchable within each translation unit -- one plausible approach is > to recognize extern "C" and extern "C++" in C, another is #pragma. I was thinking more about optimization: ensure that there's no abstraction penalty for using a C++ compiler on C code, and that both the C and C++ compilers exploit the same optimization opportunities. - Hari -- Raja R Harinath ------------------------------ harinath@cs.umn.edu