On Wed, 2010-06-02 at 19:50 +0200, Jakub Jelinek wrote: > On Wed, Jun 02, 2010 at 06:17:25PM +0100, Richard Earnshaw wrote: > > > > On Mon, 2010-05-31 at 10:02 -0700, Mark Mitchell wrote: > > > 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. > > > > We do, of course, have one very big 'virtual function' table in gcc -- > > namely the target hooks. It would be a shame if that couldn't be made > > into a proper class with virtual functions by some arbitrary rule -- > > it's a perfect example of when they should be considered. > > And the advantage would be? > > Currently targetm is a struct with function pointers, so calling > targetm.hook_xyz (); > means reading a pointer from &targetm + off, then calling it. > If you make it a class with virtual functions and targetm > would be an object of that class, then > targetm.hook_xyz (); > call means reading pointer from &targetm (the vtable pointer), followed > by reading the function pointer from the virtual table, then calling it. > One extra memory read for hook call.
A missing virtual hook would be a build failure, rather than a runtime error. So the advantage is easier maintenance. R.
