RFC: New C++ Attribute: final

[Gabriel Dos Reis]

Joe Buck <Joe.Buck@synopsys.COM> writes:

| On Mon, Mar 01, 2004 at 08:48:08PM +0100, Gabriel Dos Reis wrote:
| > There is no doubt that people will construct examples where they
| > think they need final for C++.
| 
| Such code already exists in large amounts, but does not use "final"
| because there is no such keyword.
| 
| To work around the lack of "final", one of two approaches is taken:
| 
| a) favor speed.  In this case, non-virtual methods are used, and it is
|    forbidden (by style rules for the project) to override these methods
|    or to do derivation in such a way as to break the nonvirtual method.
| 
| b) favor safety and extensibility, sacrifice performance.  In this case,
|    calls remain virtual although there is no override anywhere.
| 
| In case a), addition of "final" would increase robustness, by allowing
| the compiler to detect design rule violations.

If the function is not virtual, which design rule violation is the
compiler going to check?  Most of the projects I've seen where the
keyword "final" might have relevance have already the classes that
require factories to create the objects.  So, it was already
impossible to derive from those.  
I'm not saying "final" is useless; just that this case should be
argued consistently.

| In case b), addition of "final" would improve performance.

For extensibility in C++, you have to work with a reference or a
pointer to a polymorphic class and the static type is, for the
majority part, different from the static part.  Therefor, the vcall
would be implied even in presence of "final".  

(a) and (b) are not the arguments that I would say really argue for
"final". They just provide opportunities for the opponents to get
renforced in their opinions.

I find that stating clearly that a non-polymorphic class should not be
used as a base class (which is known in a more polite way as item xxx
of Effective C++) is much easier to achieve with final than without.

-- Gaby