This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: RFC: New C++ Attribute: final
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.
> Yes, but we need to (1) audit how good we already are at issue the
> "final" semantics implied current situations (we're near zero)
It can't possibly help the case above. The case above calls for a
different semantics, that isn't provided by GCC. It's not a matter of
getting the compiler clever enough to optimize away the dynamic call:
in C++ the call *must* be dynamic if the dynamic type overrides
foo::f(iterator). But in the case I propose, it would be possible to
specify that dynamic binding is not to be done in the computed pointer
to member.
> And we're shouting for a new keyword. Before you call me a rigid guru,
Have I? I don't think so. I just pointed out yet another case that
could benefit from a final keyword, but used in a different context
than that most people think of for the keyword final.
--
Alexandre Oliva http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org}