This is the mail archive of the
mailing list for the GCC project.
Re: Using C++ in GCC is OK
- From: Ian Lance Taylor <iant at google dot com>
- To: gcc at gcc dot gnu dot org
- Date: Thu, 03 Jun 2010 13:27:51 -0700
- Subject: Re: Using C++ in GCC is OK
- References: <4C030228.email@example.com> <AANLkTimzVEXsE4vOZJuegnHFu-pVyNdKImcasoSX_ZDc@mail.gmail.com> <4C039253.firstname.lastname@example.org> <AANLkTikp-gTh4bCpAFYWhU7fR9tBTxOP6mQp9TAfideB@mail.gmail.com> <4C03EB8D.email@example.com> <firstname.lastname@example.org>
Steinar Bang <email@example.com> writes:
>>>>>> Mark Mitchell <firstname.lastname@example.org>:
>> 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.
> Umm...? Virtual functions are _the_ core C++ feature for creating OO
GCC is a compiler, not an OO framework.
I expect we are going to to want to use virtual functions in a few
places, but I don't see why we would ever use them widely. In the
gccgo frontend I use them in the IR, but I don't see why gcc proper
would need or want to adopt that given the existing IRs.
The only other place I use them in the gccgo frontend is in the import
reader, where I use them to read either import data from a couple of
different types of input sources.
In gcc we currently use various structs of hook functions which could
be replaced by virtual functions, but as Jakub has pointed out that
would introduce an additional memory read to each use of a hook. If
we were starting from scratch we would probably use virtual functions,
but going from where we are not to using virtual function doesn't seem
like a win.