Re: RFC: New C++ Attribute: final

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

Alexandre Oliva <aoliva@redhat.com> writes:

| On Mar  2, 2004, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:
| 
| > Alexandre Oliva <aoliva@redhat.com> writes:
| 
| > | Sure, but that's besides the point.  In the case at hand, the object
| > | *may* have a derived type that overrides the member function, but the
| > | other member function actually wanted the non-overridden function to
| > | be called.
| 
| > Like a local class?  ;-)
| 
| Err...  I don't think so.  Consider:
| 
| struct base {
|   typedef /* whatever */ iterator;
|   iterator begin();
|   iterator end();
|   virtual void f(iterator);
| };
| struct foo : base {
|   void f(iterator) { do_something(); }
|   void g() {
|     call_func_for_each(this,
|                        & __extension__ __attribute__((__final__))
|                            foo::f,
|                        begin(), end());
|   }
| };
| struct derived : foo {
|   void f(iterator);
| };
| 
| The idea is to not have derived::f called by call_func_for_each, but
| rather foo::f, even if g() is called for an object of type derived.
| 
| I don't quite see how this relates with local classes.

I believe you completely missed what I was saying.

   struct bar {
     virtual void fun();
   }; 

   inline void call_fun(bar* b) {
     b->fun();
   }

   void foo()
   {
      struct foobar : bar {
      };
    
     foobar b;

     call_fun(&fb);
   }

Look at the assembly.

In the local class foo::foobar, fun() is not overriden and there is no
possible way, the call to fun() could be something other than
bar::fun. GCC, however, doesn't optimize  the vcall.

The call has all the type information there that said this is final,
it just isn't using it. I'm not saying I'm against "final"; I'm saying
if the compiler was already doing its job.

-- Gaby