This is the mail archive of the
mailing list for the GCC project.
Re: Using C++ in GCC is OK
- From: Paolo Bonzini <bonzini at gnu dot org>
- To: basile at starynkevitch dot net
- Cc: Mark Mitchell <mark at codesourcery dot com>, GCC <gcc at gcc dot gnu dot org>
- Date: Tue, 01 Jun 2010 10:31:29 +0200
- Subject: Re: Using C++ in GCC is OK
- Newsgroups: gmane.comp.gcc.devel
- References: <4C030228.email@example.com> <1275283728.21123.24.camel@glinka> <4C03DB74.firstname.lastname@example.org> <1275323168.22465.12.camel@glinka>
On 05/31/2010 06:26 PM, Basile Starynkevitch wrote:
On Mon, 2010-05-31 at 08:53 -0700, Mark Mitchell wrote:
There's no reason to get into these kinds of questions at this point.
The goal is not to reimplement GCC from the ground up using modern
OO/C++ techniques. The goal is simply to permit ourselves to use C++
features where appropriate in the codebase.
Except that perhaps these questions are important for any gengtype
enhancement. In particular, one could consider that marking a GTY-ed
data would be done by a virtual method (generated by gengtype), and then
having every GTY-ed data inheriting from an abstract class providing
this method will make both gengtype& ggc*.c simpler.
The same can be said about PCH serialization, or debug dumping.
I'm not sure. Virtual methods have the overhead of a pointer in the
object, while gengtype does 100% static typing so it doesn't need a
Also, in general compiler IRs are used in so many places that a "pattern
matching" style (similar to ML) actually works better than a "class
hierarchy" style. In other words, I doubt that C++ would remove many of
the switch statements we have in the code. With respect to this, I'm
curious about Ian's experience with gccgo.
Adjusting RTL and trees involve a huge rewrite effort, as pointed out
elsewhere in the thread, and in the end our own DSL would probably suit
the task just as well (or better). In particular, our trees have a kind
of multiple inheritance.
Personally, the first place where I'd start using C++ is the pass
manager. Even then, I'm wary about the compile-time cost of passing
"this" around all the time.
But then I have no time for anything of this, so I can just as well shut up.