This is the mail archive of the
mailing list for the GCC project.
Re: Using C++ in GCC is OK
Richard Guenther wrote:
> Oh - and we didn't yet decide to switch to C++ as implementation
> language. Did we?
I'm not sure exactly what you're asking. We now have permission to
switch. The reason we wanted permission to switch was that there was a
consensus that we wanted to switch; as far as I know, we didn't want the
permission just so that we could at some later point consider switching!
I think we've decided to switch, but we haven't decided to what subset
of C++ we're switching. I think that we want what might be called the
"syntactic sugar" subset. For example, single inheritance to replace
our C-style inheritance, constructors/destructors to replace explicit
calls to required initialization/finalization functions, and member
functions to implement ADTs, namespaces to save us some typing.
None of these things impacts memory use, or run-time performance.
Generally speaking, these are things that remove lines of code, help to
prevent mistakes made by casting or forgetting to obey requirements of
APIs, and make it easier to replace particular components without
impacting large parts of the rest of the source code.
The more "exotic" bits of C++ (RTTI, exceptions, virtual inheritance,
templates, etc.) all involve the compiler doing a lot more implicit
generation of data structures and code, including, in some cases,
implicitly making data structures bigger. I think these techniques are
valuable when used appropriately, but I wouldn't propose using them in
GCC soon. It is easy to mis-use them and for them to have unintended
I think virtual functions are on the edge; quite useful, but do result
in the compiler adding a pointer to data objects and in uninlinable
indirect calls at run-time. Therefore, I would avoid them in the
initial subset of C++ used in GCC.
(If we decide at some point, for example, that we want to be able to use
multiple back-ends in a single compiler, then virtual functions are a
good way of implementing that -- but we need to understand that there
will be an indirection for every call to a back-end function. If that's
too high a price to pay, then we won't want to do that. The point here
is that "use virtual functions" should not be the goal; the goal should
be "multiple back-ends" and then "use virtual functions" is just an
implementation technique, with costs approximately equivalent to doing
the same thing "by hand" in C.)
I am certainly a "C++ guy", and I feel that all these features have
their place, but I think we should err on the side of using less of C++,
rather than more. We have C code that works, and we have a group of
developers comfortable in C. We lose if we break our code, and even
more if alienate those developers.
(650) 331-3385 x713