Re: RFC: New C++ Attribute: final

[Joe Buck <Joe dot Buck at synopsys dot COM>]

On Mon, Mar 01, 2004 at 07:46:55PM +0100, Gabriel Dos Reis wrote:
> While not stating my opinion on that keyword, a frequent counter
> argument (that I rather find persuasive) is that "final" when defended
> as above is presented as a feature for "write-only codes with no proper
> design".  

Every problem in computer science can be solved by an extra level of
indirection.  Or rather, every problem other than inadequate performance.

Such claims usually come from those who follow rigid ideological
approaches to object-oriented design.  If I propose to have a general
matrix class and then some derived matrix classes that are tuned to
optimize particular operations, these overly rigid gurus will object if I
want to mark any operations in the tuned subclasses as final, because the
guru will be able to come up with some theoretical reason why someone will
want to further subclass the tuned implementations and therefore insists
that I destroy the performance (by making all the operations virtual).
The usual workaround is to have two versions of all the speed-critical
operations: a nonvirtual way to access elements, and a virtual way.  But
if this is done, the result is highly brittle, because it effectively
creates "final" functions that are not correctly enforced by the language.

Sigh.  I wish I could track down the "C++ at work" paper that demonstrated
how it could be used to implement a high-performance and flexible matrix
library.  Currently you can get high-performance customization by using
STL approaches and avoiding virtual functions entirely, but then you can't
pass your customized object to a single function that does the right thing
by means of virtual calls (unless you then write special "accessor"
objects or some other kludge).