This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: gengtype needs for C++?
- From: Jonathan Wakely <jwakely dot gcc at gmail dot com>
- To: basile at starynkevitch dot net
- Cc: Ian Lance Taylor <iant at google dot com>, gcc at gcc dot gnu dot org, tromey at redhat dot com, jeremie dot salvucci at free dot fr, laurynas dot biveinis at gmail dot com
- Date: Tue, 29 Jun 2010 00:42:35 +0100
- Subject: Re: gengtype needs for C++?
- References: <1277760198.29547.41.camel@glinka> <mcrzkye92nj.fsf@google.com> <1277767159.29547.62.camel@glinka>
On 29 June 2010 00:19, Basile Starynkevitch wrote:
> On Mon, 2010-06-28 at 16:08 -0700, Ian Lance Taylor wrote:
>> Basile Starynkevitch <basile@starynkevitch.net> writes:
>>
>> > * I don't know exactly what should be wished with respect to templates.
>> > Tom Tromey (in CC) have a wonderful insight in
>> > http://gcc.gnu.org/ml/gcc/2010-06/msg00143.html but I probably did not
>> > understood all the details & the consequences. In particular I don't
>> > understand if the mark method in his example has to be supplied or
>> > generated.
>>
>> In Tom's interesting idea, we would write the mark function by hand for
>> each C++ type that we use GTY with.
>>
>> One way to make this approach work for plugins would be to write
>>
>> template<typename T>
>> void
>> mark(T& t)
>> {
>> ? t->mark();
>> }
>>
>> Then every plugin which invents new garbage collected types would have
>> to define a mark method for them.
>
> Isn't that precise statement a good use case for virtual methods?
No. Not at all.
> In other words, for that trick to work for plugins, don't we require the
> mark() method above to be virtual?
No. The mark method just needs to do whatever is needed to mark the
type. T& is not a reference to base. T doesn't need to derive from a
single base class. A virtual function is completely unnecessary.
The template function can be instantiated for any T, and will call a
function T::mark, it doesn't need to be virtual for that to work.
> I would be delighted with that, but I understood that many people don't
> want to have virtual methods.
There is no need to have virtual functions here.