This is the mail archive of the
mailing list for the GCC project.
Using C++ in gcc (was Re: [RFC] type safe trees)
- From: Matt Austern <austern at apple dot com>
- To: kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)
- Cc: gcc at gcc dot gnu dot org, nick at dsvr dot net
- Date: Fri, 25 Jun 2004 10:48:21 -0700
- Subject: Using C++ in gcc (was Re: [RFC] type safe trees)
- References: <10406251531.AA10774@vlsi1.ultra.nyu.edu>
On Jun 25, 2004, at 8:31 AM, Richard Kenner wrote:
This would only be an issue if you are using C++ features like
handling and class definitions that require vtables and
constructors/destructors to be handled by the linker.
Right, that's what I said.
The proposal was to use only a tiny set of C++ features.
The *current* proposal. But I think everybody agrees that once we take
that first step, it's going to get easier and easier to add more.
the real question, given human nature, of whether it's best not to take
that first step.
That's basically what I see as the heart of the debate.
I'm still not sure whether I think that it's a good idea to use C++ in
gcc. I'm pretty sure of these two things, though:
(1) I don't believe the argument above is a good reason not
to use C++. The argument above has two parts: that once
we start using any parts of C++ there will be no reason not
to use all of the language, and that this will have bad
consequences because some parts of the C++ language
are unsuitable for our purposes. Either part of that
argument might be true, but both can't be.
(2) Writing gcc in C++ is a better idea than writing it in an
invented language of our own that gets turned into C by
specially written tools. (And that's true whether or not we
call what we're doing an invented language, and whether
or not we give that new language a name.) All the
arguments against C++ are even more true for this.
If we think that pure C meets our needs, then that's fine. If we
don't, then we should be looking for an alternative language
that might serve us better. C++ is one reasonable candidate.
There are others.