This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: gengtype needs for C++?


> > 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?

In most cases, yes. You would have a pure virtual class (aka interface) that has the mark() method (and whatever other methods appear to be used in conjunction with mark), and parameterize the method with that type.

The downside is that you (and others) need to be comfortable with multiple-inheritance of pure virtual classes as a means of keeping the code in line with OO principles (namely, the Interface Segregation Principle and Open-Closed Principle). The other downside is potentially decreased performance, if it greatly affects spatial locality and you are using a compiler that doesn't do devirtualization. The upside is that you have a specific type you are parameterizing the function with, which better reveals the intention. It also yields significantly easier to read/debug compiler/linker warnings.

In some cases, templates can provide for better code locality and inlining/folding opportunities when trying to make code faster. Preemptively using templates for this purpose is perhaps a bit dubious, not that I see anyone arguing such a thing.

Some people simply have allergies to virtual functions (or even inheritance, in general) and will do just about anything to avoid their use -- including overindulgence of templates. It's sometimes not productive to try to convince them otherwise, especially if they have battle scars and nightmares of battles with C++ compilers from the 1980s. You can always wrap the code/interfaces that comply with their personal preferences with an interface that uses the technique I mention above.

I don't care what happens, but wanted to make sure you got a decent explanation :)

HTH

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]