On Tue, Jun 29, 2010 at 1:42 AM, Jonathan Wakely <jwakely....@gmail.com> wrote:
> On 29 June 2010 00:19, Basile Starynkevitch wrote:
>> On Mon, 2010-06-28 at 16:08 -0700, Ian Lance Taylor wrote:
>>> Basile Starynkevitch <bas...@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.
I think the idea was to have
template <typename T>
void mark (T&);
and specializations for all types that are known at GCC compile-time.
Then, for plugins we would provide a general implementation using
virtual functions like
struct PluginGGCObject { virtual void mark () = 0; }
template <>
void mark (PluginGGCObject&o) { o->mark(); }
and if plugins want to use new GGC managed types they have to
derive from PluginGGCObject and implement a virtual mark method.
That avoids virtual functions for types we know at compile-time
of GCC and allows easy flexibility in plugins.
Richard.
