This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Converting GCC to compilation with C++
- From: rd flowers <rd at chatta dot us>
- To: gcc at gcc dot gnu dot org
- Date: Thu, 15 Jul 2004 21:50:44 +0100
- Subject: Re: Converting GCC to compilation with C++
- References: <1089737834.21011.ezmlm@gcc.gnu.org>
- Reply-to: rdflowers <chatta at chatta dot us>
Subject:
RE: Converting GCC to compilation with C++
From:
"Dave Korn" <dk@artimi.com>
Date:
Tue, 13 Jul 2004 16:19:49 +0100
To:
<gcc@gcc.gnu.org>
Absolutely: note that in my original posting, the source of my concerns
was the proposal from R.D. Flowers that we could permit the gcc sources to
use gcc-specific extensions; that indeed would prevent non-gnu tools from
being used to compile gcc of course.
This particular issue was tangential to the C-vs-C++ debate, which I then
addressed in the second paragraph. The two issues (gcc source using gcc
extensions => can't compile with non-gnu tools) and (does using C++ make
compiling any harder) were only tangentially related.
It only means that there should
be some computer enforced policy in place.
There might well be a lot to be said for having auto coding standards
checkers that work like the regression checkers. A sound - and well
enforced! - policy on the use and limitations of C++ would go a long way to
assuage my reservations.
cheers,
DaveK
=====================================================================
To clarify my suggestion --
I would
1. Use those extensions ONLY that are a subset of some conservative
version of C++ (that the rest of gcc including the extensions should
also be compilable with (but not require) standard c++ tools).
2. Not have a few new , separately-selectable switches, but rather that
any extensions used for this would be enabled/disabled as a package deal
(except for any use of existing extensions that people are used to).
This might both discourage addiction and otherwise lessen the config and
maintenance burden.
3. Other limitings that I agree with (both via culture and via
automation) have already been mentioned.
Would not the requirement of c++ versus C be a bigger barrier then the
occasional need to go from a binary rather than from source at the start?