From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-70997-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 18814 invoked by alias); 25 Mar 2003 22:13:57 -0000
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Archive: <http://gcc.gnu.org/ml/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <http://gcc.gnu.org/ml/>
Sender: gcc-owner@gcc.gnu.org
Received: (qmail 18806 invoked from network); 25 Mar 2003 22:13:55 -0000
Received: from unknown (HELO mail.kloo.net) (63.192.214.25)
  by sources.redhat.com with SMTP; 25 Mar 2003 22:13:55 -0000
Received: by mail.kloo.net (Postfix, from userid 504)
	id 53E6D3B0308; Tue, 25 Mar 2003 15:03:39 -0800 (PST)
Received: from localhost (localhost [127.0.0.1])
	by mail.kloo.net (Postfix) with ESMTP
	id 5210F3B4493; Tue, 25 Mar 2003 15:03:39 -0800 (PST)
Date: Tue, 25 Mar 2003 22:23:00 -0000
From: <tm_gccmail@mail.kloo.net>
To: Raja R Harinath <harinath@cs.umn.edu>
Cc: Zack Weinberg <zack@codesourcery.com>,
	"Kaveh R. Ghazi" <ghazi@caip.rutgers.edu>, mark@codesourcery.com,
	gcc@gcc.gnu.org, gdr@integrable-solutions.net
Subject: Re: Converting to ISO C89
In-Reply-To: <d9llz36rdq.fsf@bose.cs.umn.edu>
Message-ID: <Pine.LNX.4.21.0303251501170.27137-100000@mail.kloo.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-SW-Source: 2003-03/txt/msg01580.txt.bz2

On Tue, 25 Mar 2003, Raja R Harinath wrote:

> Hi,
> 
> Zack Weinberg <zack@codesourcery.com> writes:
> 
> > Raja R Harinath <harinath@cs.umn.edu> 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

IIRC, C code compiled as C++ needs to carry around stack unwinding
information whereas C code compiled as C does not.

Therefore, the abstraction penalty cannot be zero in terms of code size.

Toshi