This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Using C++ in GCC is OK
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Ian Lance Taylor <iant at google dot com>
- Cc: Mark Mitchell <mark at codesourcery dot com>, GCC <gcc at gcc dot gnu dot org>
- Date: Fri, 4 Jun 2010 20:15:44 +0000 (UTC)
- Subject: Re: Using C++ in GCC is OK
- References: <4C030228.8020201@codesourcery.com> <mcrhblnnuz3.fsf@dhcp-172-17-9-151.mtv.corp.google.com>
On Mon, 31 May 2010, Ian Lance Taylor wrote:
> I have written a proposed set of C++ coding conventions on the wiki at
> http://gcc.gnu.org/wiki/CppConventions
>
> This is only a preliminary proposal. It requires fleshing out and
> discussion. Comments welcome.
I think the coding style warning option is an important piece to get in
early before many C++ changes are made.
I propose GCC 4.1 as the baseline GCC version that should be able to build
versions of GCC built as C++. (PPL requires at least 4.0 so anyone
building a Graphite-enabled compiler will have a 4.0 or later C++ compiler
for the host, and 4.1 was more widely used than 4.0.)
In addition to what I said about avoiding any bulk changes to formatting
conventions, I think there should be a principle that changes of existing
code to use C++ features should generally improve the maintainability and
comprehensibility of the code. Conversion to standard C++ features where
macros are used to emulate e.g. templates (STL or otherwise) or
inheritance is much more desirable than converting qsort calls to
std::sort since qsort is a well-understood standard C feature rather than
a pile of GCC-specific macros.
I repeat my request from the RM Q&A for a guide for reviewers on how to
detect hidden overhead in the presence of C++ features. When will a
structure/class/union be larger than might be expected in C? When will
C++ statements involve runtime overhead that might not be expected from
equivalent C statements?
--
Joseph S. Myers
joseph@codesourcery.com