Re: RFC: New C++ Attribute: final

[Joe Buck <Joe.Buck@synopsys.COM>]

On Wed, Mar 03, 2004 at 06:24:37PM +0100, Gabriel Dos Reis wrote:
> More to the point, the case I just pointed out *is* an instance where
> the function has final semantics and the compiler knows that. 
> 
>   (1) In my case, it is known after the class foobar definition
>       that foobar::fun is final.  The compiler does not optimize the
>       vcall.  I don't think a keyword is needed for that.
>       Usage of local classes like that are common.
> 
>   (2) in the testcase I gave to Joe, I'm pointing out that GCC still
>       don't quite understand pointer-to-member-function and optimize
>       accordingly. And this is a case where all information are
>       available, in the specific context the call is made.
> 
> I'm saying that given both (1) and (2), it looks like we would be
> trumping people, for they are already saying "final" and we don't optimize.

Agreed; the first thing we need to do is get the compiler to do a better
job generating good code for ISO C++.

> Those two cases do not cover all the semantics that a putative "final"
> may have; but if we optimize those cases  (which are quite common,
> probably more common than the other corner cases) then we may be more
> credible in saying that a keyword is needed to do a better job.

I am interested in "final" not just to do a better job of optimization,
but also for improved safety; there are many codes that implicitly assume
"final" for correct operation (some gurus believe such codes are "broken"
but any GNU/Linux distro is full of such "broken" code).  Just the same,
Gaby is right; we need to do a better job of avoiding virtual calls in
cases where the compiler already can determine that a specific function
must be called.