RFC: New C++ Attribute: final

RFC: New C++ Attribute: final

[Kevin Atkinson]

I have an idea for a new C++ attribute, and would like to know what others 
think of it:

'final'

Marks a virtual function of an entire class as being "final", in the sense 
that it can not be overridden in a derived class.  If it is applied to a 
type then every virtual function in the class will be considered final.  
It will not, however, keep a class from being inherited from.  
Gcc will produce a warning (or maybe an error) if a "final" method is 
overridden.

The primary purpose of this attribute is to serve as an optimization hint 
so that a virtual function call does not need to be used.  It will also 
allow gcc to perhaps inline the function call if it is appropriate.

An example:

class A {
public:
  virtual void f();
};

class B {
public:
  __attribute__((final)) void f();
};

int main()
{
  B * b = new B;
  A * a = b;
  a->f(); // virtual call
  b->f(); // non virtual call since the function in type B is marked
          // as final
  b->B::f(); // equalvent to the above
}

I have not written any code for GCC yet, but if people think it is a good 
idea I may just implement this, as it seams like something that can't be 
too difficult to do.

-- 
http://kevin.atkinson.dhs.org

Re: RFC: New C++ Attribute: final

[Mark Mielke]

Trying to make C++ look like Java, are we? :-)

mark


On Sat, Feb 28, 2004 at 09:43:19PM -0500, Kevin Atkinson wrote:
> 
> I have an idea for a new C++ attribute, and would like to know what others 
> think of it:
> 
> 'final'
> 
> Marks a virtual function of an entire class as being "final", in the sense 
> that it can not be overridden in a derived class.  If it is applied to a 
> type then every virtual function in the class will be considered final.  
> It will not, however, keep a class from being inherited from.  
> Gcc will produce a warning (or maybe an error) if a "final" method is 
> overridden.
> 
> The primary purpose of this attribute is to serve as an optimization hint 
> so that a virtual function call does not need to be used.  It will also 
> allow gcc to perhaps inline the function call if it is appropriate.
> 
> An example:
> 
> class A {
> public:
>   virtual void f();
> };
> 
> class B {
> public:
>   __attribute__((final)) void f();
> };
> 
> int main()
> {
>   B * b = new B;
>   A * a = b;
>   a->f(); // virtual call
>   b->f(); // non virtual call since the function in type B is marked
>           // as final
>   b->B::f(); // equalvent to the above
> }
> 
> I have not written any code for GCC yet, but if people think it is a good 
> idea I may just implement this, as it seams like something that can't be 
> too difficult to do.
> 
> -- 
> http://kevin.atkinson.dhs.org

-- 
mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________
.  .  _  ._  . .   .__    .  . ._. .__ .   . . .__  | Neighbourhood Coder
|\/| |_| |_| |/    |_     |\/|  |  |_  |   |/  |_   | 
|  | | | | \ | \   |__ .  |  | .|. |__ |__ | \ |__  | Ottawa, Ontario, Canada

  One ring to rule them all, one ring to find them, one ring to bring them all
                       and in the darkness bind them...

                           http://mark.mielke.cc/

Re: RFC: New C++ Attribute: final

[Kevin Atkinson]

On Sun, 29 Feb 2004, Mark Mielke wrote:

> Trying to make C++ look like Java, are we? :-)

Well yes I got the name from Java.  But that doesn't mean that it can't be 
useful is C++ also.  Furthermore this attribute is mainly an 
optimization so your program will still be correct without it.  

-- 
http://kevin.atkinson.dhs.org

Re: RFC: New C++ Attribute: final

[Phil Edwards]

On Sat, Feb 28, 2004 at 09:43:19PM -0500, Kevin Atkinson wrote:
>   b->f(); // non virtual call since the function in type B is marked
>           // as final
>   b->B::f(); // equalvent to the above

So, what's the benefit?  If that user wants a non-virtual call, he can
specify the latter, and it will be more portable and obvious to anyone
reading the code.

-- 
I would therefore like to posit that computing's central challenge, viz. "How
not to make a mess of it," has /not/ been met.
                                                 - Edsger Dijkstra, 1930-2002

Re: RFC: New C++ Attribute: final

[Kevin Atkinson]

On Sun, 29 Feb 2004, Phil Edwards wrote:

> On Sat, Feb 28, 2004 at 09:43:19PM -0500, Kevin Atkinson wrote:
> >   b->f(); // non virtual call since the function in type B is marked
> >           // as final
> >   b->B::f(); // equalvent to the above
> 
> So, what's the benefit?  If that user wants a non-virtual call, he can
> specify the latter, and it will be more portable and obvious to anyone
> reading the code.

Well because the user has to remember to use B::f() instead of f() every 
time.  If a virtual method is "final" either by relaying on the user to 
not override it (by putting a comment in the header file) or forced by the 
compiler (with __attribute__((final)) or just "final" in have) than infact 
b->f() and b->B::f() will have the exact same effect except that the 
latter is more effect since it is a direct function call and not a virtual 
one.  Thus the __attribute__((final)) is essentially an optimization hint.

Here is another example:

Suppose we start off with a simple class

class X {
  int id() const {return id_;}
private:
  int id_;
};

void find(X * x, int id) {
  while (*x && x->id() != id) ++x;
}

Now find is efficient because it assumes x->id() is inline.

Now suppose we decide that we want X to implement an interface:

class Id {
  virtual int id() const = 0;
};

class X : public Id ...

Now find suddenly become rather inefficient because the compiler can no 
longer inline x->id() since it can't be sure that there is not another 
class derived from X that overrides id(), even through the programmer 
knows this.  One solution is to change the code for find:

void find(X * x, int id) {
  while (*x && x->X::id() != id) ++x;
}

So, not such a big deal.  Now suppose there is a LOT of code that makes 
this assumption.  That ALL the code will need to be changed.

Alternatively X can be defined as:

class X {
  __attribute__((final)) int id() const {return id_;}
private:
  int id_;
};

Now the old version of find (ie the one without x->X::id()) is just as 
efficient as it was before.

This example is slightly contrived but it is based on a real situation in 
my own code.

-- 
http://kevin.atkinson.dhs.org

Re: RFC: New C++ Attribute: final

[Kevin Atkinson]

On Mon, 1 Mar 2004, Kevin Atkinson wrote:

> On Sun, 29 Feb 2004, Phil Edwards wrote:
> 
> > On Sat, Feb 28, 2004 at 09:43:19PM -0500, Kevin Atkinson wrote:
> > >   b->f(); // non virtual call since the function in type B is marked
> > >           // as final
> > >   b->B::f(); // equalvent to the above
> > 
> > So, what's the benefit?  If that user wants a non-virtual call, he can
> > specify the latter, and it will be more portable and obvious to anyone
> > reading the code.
> 
> Well because the user has to remember to use B::f() instead of f() every 
> time.  If a virtual method is "final" either by relaying on the user to 
> not override it (by putting a comment in the header file) or forced by the 
> compiler (with __attribute__((final)) or just "final" in have) than infact 
                                                           ^^^^ = java
> b->f() and b->B::f() will have the exact same effect except that the 
> latter is more effect since it is a direct function call and not a virtual 
> one.  Thus the __attribute__((final)) is essentially an optimization hint.
> 
> Here is another example:
> 
> Suppose we start off with a simple class
> 
> class X {
>   int id() const {return id_;}
> private:
>   int id_;
> };
> 
> void find(X * x, int id) {
>   while (*x && x->id() != id) ++x;
> }
> 
> Now find is efficient because it assumes x->id() is inline.
> 
> Now suppose we decide that we want X to implement an interface:
> 
> class Id {
>   virtual int id() const = 0;
> };
> 
> class X : public Id ...
> 
> Now find suddenly become rather inefficient because the compiler can no 
> longer inline x->id() since it can't be sure that there is not another 
> class derived from X that overrides id(), even through the programmer 
> knows this.  One solution is to change the code for find:
> 
> void find(X * x, int id) {
>   while (*x && x->X::id() != id) ++x;
> }
> 
> So, not such a big deal.  Now suppose there is a LOT of code that makes 
> this assumption.  That ALL the code will need to be changed.
> 
> Alternatively X can be defined as:
> 
> class X {
>   __attribute__((final)) int id() const {return id_;}
> private:
>   int id_;
> };
> 
> Now the old version of find (ie the one without x->X::id()) is just as 
> efficient as it was before.
> 
> This example is slightly contrived but it is based on a real situation in 
> my own code.
> 
> 

-- 
http://kevin.atkinson.dhs.org

Re: RFC: New C++ Attribute: final

[Nathan Sidwell]

Kevin Atkinson wrote:
> Well yes I got the name from Java.  But that doesn't mean that it can't be 
> useful is C++ also.  Furthermore this attribute is mainly an 
> optimization so your program will still be correct without it.  

In Java, the point of 'final' is to say 'not virtual', because all
non static member functions are implicitly virtual. In C++ there's no need.

The point of virtual functions is to allow old code to call new code,
your 'final' proposal subverts that behaviour.

what is its point?

nathan

-- 
Nathan Sidwell    ::   http://www.codesourcery.com   ::     CodeSourcery LLC
nathan@codesourcery.com    ::     http://www.planetfall.pwp.blueyonder.co.uk

Re: RFC: New C++ Attribute: final

[Per Abrahamsen]

Nathan Sidwell <nathan@codesourcery.com> writes:

> The point of virtual functions is to allow old code to call new code,
> your 'final' proposal subverts that behaviour.
>
> what is its point?

I'd use it when I want to disallow old code to call new code, in order
to be able to reason about it.  Example:

  class Base
  {
    virtual void bar () = 0;
    void foo ()
    { 
      // Do something...
      bar ();
    }
    // ...
  };
  
  class Derived : public Base
  {
    int x;
    FINAL void bar () 
    {  x = 42; }
    void baz ()
    {
      foo ();
      // This following assertion will always be true, because bar is FINAL.
      assert (x == 42);  
    }
    // ...
  };

It probably enables some automatic optimizations as well (without the
need to rewrite or uglify client code), but I care less about that.

I'd very much like to see something like this in the C++ standard, but
I believe it is against current policy to implement this kind of
experimental language design extensions in GCC.

Re: RFC: New C++ Attribute: final

[Jeff Sturm]

On Mon, 1 Mar 2004, Nathan Sidwell wrote:
> Kevin Atkinson wrote:
> > Well yes I got the name from Java.  But that doesn't mean that it can't be
> > useful is C++ also.  Furthermore this attribute is mainly an
> > optimization so your program will still be correct without it.
>
> In Java, the point of 'final' is to say 'not virtual', because all
> non static member functions are implicitly virtual. In C++ there's no need.

If a base class declares a method 'virtual' in C++, can a derived class
override the modifier, such that calls to the overridden method do
not require vtable dispatch?

Jeff

Re: RFC: New C++ Attribute: final

[Gabriel Dos Reis]

Jeff Sturm <jsturm@one-point.com> writes:

| If a base class declares a method 'virtual' in C++, can a derived class
| override the modifier, such that calls to the overridden method do
| not require vtable dispatch?

It depends on the compiler and how you organize your program.  Defunct
KCC was able to use type information from your program, do static
analyzis and optimize out vcalls.  But you can fool it, though, if
you're determined.  Note also that if you have a good linker, it can
determine most of the cases when a virtual function is not overriden
and optimize the vcall.

"final" is probably one of the most recurent keywords people want to
borrow from other programming languages and add to C++.  MS is recently
recycling it as "sealed".  The next recurent keyword probably is
"override".

-- Gaby

Re: RFC: New C++ Attribute: final

[Nathan Sidwell]

Jeff Sturm wrote:
> On Mon, 1 Mar 2004, Nathan Sidwell wrote:
> 
>>Kevin Atkinson wrote:
>>
>>>Well yes I got the name from Java.  But that doesn't mean that it can't be
>>>useful is C++ also.  Furthermore this attribute is mainly an
>>>optimization so your program will still be correct without it.
>>
>>In Java, the point of 'final' is to say 'not virtual', because all
>>non static member functions are implicitly virtual. In C++ there's no need.
> 
> 
> If a base class declares a method 'virtual' in C++, can a derived class
> override the modifier, such that calls to the overridden method do
> not require vtable dispatch?
Only when the dynamic type can be determined at compile time.

 From a programmer's perspective, why is it desirable to remove the
virtuality?

nathan

-- 
Nathan Sidwell    ::   http://www.codesourcery.com   ::     CodeSourcery LLC
nathan@codesourcery.com    ::     http://www.planetfall.pwp.blueyonder.co.uk

Re: RFC: New C++ Attribute: final

[Joe Buck]

On Sun, Feb 29, 2004 at 12:48:49AM -0500, Mark Mielke wrote:
> Trying to make C++ look like Java, are we? :-)

I first saw the suggestion for a C++ "final" keyword at a C++ conference
in, I believe, 1992, long before Java existed.

Re: RFC: New C++ Attribute: final

[Joe Buck]

On Mon, Mar 01, 2004 at 10:20:17AM +0000, Nathan Sidwell wrote:
> Kevin Atkinson wrote:
> > Well yes I got the name from Java.  But that doesn't mean that it can't be 
> > useful is C++ also.  Furthermore this attribute is mainly an 
> > optimization so your program will still be correct without it.  
> 
> In Java, the point of 'final' is to say 'not virtual', because all
> non static member functions are implicitly virtual. In C++ there's no need.

This is incorrect.  "final" permits a performance win in Java that C++
does not have, as it permits the compiler to eliminate many virtual calls.
The key is that Base::func can be labeled virtual while Derived::func
can be labeled final.  You can't do that in C++.

I first saw a proposal for "final" in C++ in the context of a paper on
the implementation of matrix classes of various forms (sparse matrix,
symmetrix matrix, general dense matrix, etc) in 1992.  The key observation
is that if we make the base element access method virtual, but then make
the derived element access methods final, we can write algorithms for the
derived classes in a natural way and avoid virtual calls.  In the absence
of "final", I've often been reduced to having two forms of calls, a
virtual form and a nonvirtual form, which can be error-prone.

Re: RFC: New C++ Attribute: final

[Joe Buck]

On Mon, Mar 01, 2004 at 03:04:40PM +0000, Nathan Sidwell wrote:
> Jeff Sturm wrote:
> > On Mon, 1 Mar 2004, Nathan Sidwell wrote:
> > 
> >>Kevin Atkinson wrote:
> >>
> >>>Well yes I got the name from Java.  But that doesn't mean that it can't be
> >>>useful is C++ also.  Furthermore this attribute is mainly an
> >>>optimization so your program will still be correct without it.
> >>
> >>In Java, the point of 'final' is to say 'not virtual', because all
> >>non static member functions are implicitly virtual. In C++ there's no need.
> > 
> > 
> > If a base class declares a method 'virtual' in C++, can a derived class
> > override the modifier, such that calls to the overridden method do
> > not require vtable dispatch?
> Only when the dynamic type can be determined at compile time.

What you are missing (or not paying enough attention to) is that the
dynamic type does not need to be determined exactly.

Consider the case where Base::func is virtual but Derived::func is final.
Then given a reference to Derived, any call to func is non-virtual.  In
particular, consider Base::func2 which is virtual and Derived::func2 which
is also virtual.  In such cases, any call to func inside Derived::func2
is non-virtual.  It does not matter if the real type is MoreDerived, which
is derived from Derived.

Normally the programmer will want to make the derived final function
inline.

Re: RFC: New C++ Attribute: final

[Gabriel Dos Reis]

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

| I first saw a proposal for "final" in C++ in the context of a paper on
| the implementation of matrix classes of various forms (sparse matrix,
| symmetrix matrix, general dense matrix, etc) in 1992.

Indeed, "final" has been repeatedly proposed for C++, repeatedly
discussed/debated, and repeatedly rejected.  It is proposed again for
the next round of C++ standardization. (I would not be surprised by
the outcome though ;-))  The guy working upstair said he had been
seeing that suggestion since CFront was released with support for
virtual fonctions :-)

comp.lang.c++.moderated and comp.std.c++ have plenty of those
discussions. 

|  The key observation
| is that if we make the base element access method virtual, but then make
| the derived element access methods final, we can write algorithms for the
| derived classes in a natural way and avoid virtual calls.  In the absence
| of "final", I've often been reduced to having two forms of calls, a
| virtual form and a nonvirtual form, which can be error-prone.

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".  

-- Gaby

Re: RFC: New C++ Attribute: final

[Joe Buck]

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).

Re: RFC: New C++ Attribute: final

[Jeff Sturm]

On Mon, 1 Mar 2004, Nathan Sidwell wrote:
> Jeff Sturm wrote:
> > If a base class declares a method 'virtual' in C++, can a derived class
> > override the modifier, such that calls to the overridden method do
> > not require vtable dispatch?
> Only when the dynamic type can be determined at compile time.

I see...

>  From a programmer's perspective, why is it desirable to remove the
> virtuality?

For C++, I can't think of a good reason besides performance.  In Java, I
think 'final' is essential to the security framework.

In practice we often use 'final' to trigger a compilation error if someone
tries to override a method we wouldn't normally expect to be overridden,
if only to force the developer to examine it closely.  However the first
time someone removes the final modifier, we lose that benefit.

Jeff

Re: RFC: New C++ Attribute: final

[Gabriel Dos Reis]

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

| 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.

More precisely, such claims often come from people with particular
views on what object-oriented design means.  That does not mean that
such claims always come from those people.  In particular such
arguments should be analyzed on their own basis, not based on the religion
of the persons one may think it comes from.

|  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).

I don't know of the gurus you have had to speak with, but the ones I
have had spoken and work with just don't use virtual functions for
matrices or any other classes that have value semantics.  Not that
they don't like what is fuzzily called "object oriented" programming
-- they actually have design in layers where the non-"computational"
part is presented to users through abstract classes.  They also use
multiple inheritance where appropriate to satisfy a given interface --
usually the inherited concrete Matrix is non-polymorphic and the
interface is implemented in terms of those "concrete" classes.
They don't invoke any theoretical arguments:  their classes where
value based and they saw no reason to say differently in their
implementations. 

I sympathize you weren't successful in convincing the gurus you had to
speak with, but I would not reject such claims just because you had
spoken to  gurus you could not convince.  But I doubt that arguments
that speak of rigid ideological approaches to obejct-oriented design
or such will turn people mind into suddendly accepting the keyword.
(Quiz: Who is ideological?  The people  insisting or the people
rejecting?)  C++98 has missed useful and important features partly
because some proponents have taken the approach of treating their
opponents as "ignorant", "rigid", or "middle class anglo-saxons".
Such characterizations just inflame the debate with bringing a
valuable benefit, at least as far as the proposed features are
concerned. (It is a case where one would prefer not to have such
proponents :-))

I hope anyone interested in defending that keyword before the C++
committee  would not fall into that trap again.

-- Gaby

Re: RFC: New C++ Attribute: final

[Gabriel Dos Reis]

Jeff Sturm <jsturm@one-point.com> writes:

| >  From a programmer's perspective, why is it desirable to remove the
| > virtuality?
| 
| For C++, I can't think of a good reason besides performance.  In Java, I
| think 'final' is essential to the security framework.

There is no doubt that people will construct examples where they
think they need final for C++.  Similarly, there is no doubt people
will come up with techniques and arguments why that need is a
"ill-design" artefact.  Which is what has been happening since ages.
If you argue your case by saying that one approach is ideological,
you would have  trouble arguiing convincingly why the other is not.  

-- Gaby

Re: RFC: New C++ Attribute: final

[Joe Buck]

On Mon, Mar 01, 2004 at 08:38:43PM +0100, Gabriel Dos Reis wrote:
> I don't know of the gurus you have had to speak with, but the ones I
> have had spoken and work with just don't use virtual functions for
> matrices or any other classes that have value semantics.  Not that
> they don't like what is fuzzily called "object oriented" programming
> -- they actually have design in layers where the non-"computational"
> part is presented to users through abstract classes.

I addressed this point when I described the alternative of using
STL-style approaches coupled with adapters, which can be implemented
as abstract classes.  Yes, this approach can be made to work, but it
requires the building of two designs rather than one: completely
nonvirtual computation coupled with virtual accessors. 

> I sympathize you weren't successful in convincing the gurus you had to
> speak with, but I would not reject such claims just because you had
> spoken to  gurus you could not convince.  But I doubt that arguments
> that speak of rigid ideological approaches to obejct-oriented design
> or such will turn people mind into suddendly accepting the keyword.
> (Quiz: Who is ideological?  The people  insisting or the people
> rejecting?)

I brought this up in response to your claim (OK, you say it is not your
claim, merely one that you are passing on) that those advocating "final"
are presenting it as a feature for "write-only codes with no proper
design".  Such claims are ideological (implying as they do that designs
that would benefit from "final" are not proper), and are contradicted by
proven designs in Java.  The only other objection I saw is that Java needs
"final" because the default is virtual, which misses the point that a
final member function can override a virtual member function of the base
class).

> C++98 has missed useful and important features partly
> because some proponents have taken the approach of treating their
> opponents as "ignorant", "rigid", or "middle class anglo-saxons".

I would argue that those that claim that the "final" concept is a feature
for "write-only codes with no proper design" are doing just this.

Re: RFC: New C++ Attribute: final

[Joe Buck]

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.

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

Re: RFC: New C++ Attribute: final

[Gabriel Dos Reis]

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

| > I sympathize you weren't successful in convincing the gurus you had to
| > speak with, but I would not reject such claims just because you had
| > spoken to  gurus you could not convince.  But I doubt that arguments
| > that speak of rigid ideological approaches to obejct-oriented design
| > or such will turn people mind into suddendly accepting the keyword.
| > (Quiz: Who is ideological?  The people  insisting or the people
| > rejecting?)
| 
| I brought this up in response to your claim (OK, you say it is not your

It is not my claim.  I do not hide my claims under others'.
However, it is not totally unfounded and I find it persuasive.  Which
does not mean I'm for or I'm against.  I can perfectly find an
argument persuasive and reject following it or decide to slavishly abide.
  
If you think, I'm ideological, just say so -- for I have not stated my
opinion on this keyword.  

| claim, merely one that you are passing on) that those advocating "final"

I'm not known as a "mouton de Panurge".  I weight both sides before
deciding especially when it is a recurring theme (meaning it is not
set once for all).  This issue is not a white-or-black  issue.
Contrary to you, I do not think that the opponent are totally rigid;
simularly, I do not think the proponent are totally stupid.  The truth
is somewhere in the middle.

| are presenting it as a feature for "write-only codes with no proper
| design".  Such claims are ideological (implying as they do that designs

I do not believe they are more ideological than the reasons that push
the proponents to bring up the issue in the first place.

| that would benefit from "final" are not proper), and are contradicted by
| proven designs in Java.  The only other objection I saw is that Java needs

Well, I don't think features from one programming language translate
to another like that.  One distinctive feature of Java is that by
default everything is virtual and you hardly have multiple
inheritance.  Therefore one is kind of limited, and I clearly see why
I would argue for final in Java.  For C++, I think I have reasons to
argue for "final", but I also can see reasons why mines or others'
presented here are not as strong as in the case of Java.

| "final" because the default is virtual, which misses the point that a
| final member function can override a virtual member function of the base
| class).
| 
| > C++98 has missed useful and important features partly
| > because some proponents have taken the approach of treating their
| > opponents as "ignorant", "rigid", or "middle class anglo-saxons".
| 
| I would argue that those that claim that the "final" concept is a feature
| for "write-only codes with no proper design" are doing just this.

As I said in a previous message, arguments along those lines have been
unsuccessful in the past.  I doubt they will succeed for the next
round.  In fact, I think that proponents arguing along those lines
are sabotaging the cause. 

-- Gaby

Re: 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

Re: RFC: New C++ Attribute: final

[Kevin Atkinson]

On Mon, 1 Mar 2004, Per Abrahamsen wrote:

> I'd very much like to see something like this in the C++ standard, but
> I believe it is against current policy to implement this kind of
> experimental language design extensions in GCC.

Well implementing an "experimental language design extensions in GCC" will 
(perhaps greatly) increase the chances that it will appear in the next 
C++ standard.  Furthermore much like "format" attribute, it will not 
change the behavior of a "correct" program.  By "correct" I mean a program 
witch does not override a virtual function which is marked as "final". 

-- 
http://kevin.atkinson.dhs.org

Re: RFC: New C++ Attribute: final

[Joe Buck]

I'm not going to address all your points, because we will just have to
agree to disagree.  However:

On Mon, Mar 01, 2004 at 09:47:33PM +0100, Gabriel Dos Reis wrote:
> 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".  

Given virtual Base::func and final Derived::func, if the compiler sees
a reference to Base, it generates a virtual call.  If the compiler sees
a reference to Derived, it generates a nonvirtual call, even though
the static type might be something else.  So the answer is that sometimes
it is implied and sometimes it is not, but we always call the correct
function.

> (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.

We pretty much proved that Effective C++'s recommendations are broken.  If
you forget how we did that, just supply -Weffc++ to GCC and watch the fun.
In particular, STL gives you seas of warnings, because it cannot be
implemented (with acceptable performance) without deriving from base
classes without using virtual functions or virtual destructors.  Our STL
implementation is filled with non-polymorphic classes that are used as
base classes.

Re: RFC: New C++ Attribute: final

[Gabriel Dos Reis]

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

| I'm not going to address all your points, because we will just have to
| agree to disagree.  However:

I have no problem disagreeing with you that your qualification of rigid
does not help the issue.  I, however, would not disgree that "final"
may have some potential benefits for some C++ codes.  That does not
mean I'm for/against that keyword/attribute.  But, I refuse rejecting
opponents' arguments by religious labelling.   

| On Mon, Mar 01, 2004 at 09:47:33PM +0100, Gabriel Dos Reis wrote:
| > 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".  
| 
| Given virtual Base::func and final Derived::func, if the compiler sees
| a reference to Base, it generates a virtual call.  If the compiler sees
| a reference to Derived, it generates a nonvirtual call, even though
| the static type might be something else.  So the answer is that sometimes
| it is implied and sometimes it is not, but we always call the correct
| function.

There were no doubt the correct function would be called (and I hope
the initial poster at least agree on that).  The issue concerned
rather the "sometines", whether it argues sufficiently strong --
compared to other alternative.

| > (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.
| 
| We pretty much proved that Effective C++'s recommendations are broken.  If

No.  What modern C++ proves is that *undiscriminated* applications of
Effective C++'s rules are at odd with current practice.  However,
informed applications (e.g. use of "final" to state that intention in
the class defintion, instead of having the compiler second-guessing)
of those rules are still welcome useful for real-codes.  

| you forget how we did that, just supply -Weffc++ to GCC and watch the fun.

I forgot nothing.  If you google a bit you'll not be surprised to find some
of messages about -Weffec++..

| In particular, STL gives you seas of warnings, because it cannot be
| implemented (with acceptable performance) without deriving from base
| classes without using virtual functions or virtual destructors.  Our STL
| implementation is filled with non-polymorphic classes that are used as
| base classes.

Can you assume I know that? If not, just google ;-)  I even happen to
be a perpetrator of that fact elsewhere in our library.

-- Gaby

Re: RFC: New C++ Attribute: final

[Robert Dewar]

Per Abrahamsen wrote:
> Nathan Sidwell <nathan@codesourcery.com> writes:
> 
> 
>>The point of virtual functions is to allow old code to call new code,
>>your 'final' proposal subverts that behaviour.
>>
>>what is its point?
> 
> 
> I'd use it when I want to disallow old code to call new code, in order
> to be able to reason about it. 

Note that this may also be useful in an environment requiring
formal certification.

Re: RFC: New C++ Attribute: final

[Nathan Sidwell]

Joe Buck wrote:
> On Mon, Mar 01, 2004 at 03:04:40PM +0000, Nathan Sidwell wrote:
> 
>>Jeff Sturm wrote:
>>
>>>On Mon, 1 Mar 2004, Nathan Sidwell wrote:
>>>
>>>
>>>>Kevin Atkinson wrote:

>>>If a base class declares a method 'virtual' in C++, can a derived class
>>>override the modifier, such that calls to the overridden method do
>>>not require vtable dispatch?
>>
>>Only when the dynamic type can be determined at compile time.
> 
> 
> What you are missing (or not paying enough attention to) is that the
> dynamic type does not need to be determined exactly.
Joe, that question was about C++, not about 'C++ with final'.  I wanted
to get a handle on whether 'final' had more to it than the virtual
dispatch optimization we are both talking about.  You've provided
plenty of examples where final would be useful in both efficiency and
language expressibility domains, that is good, thank you.

nathan

-- 
Nathan Sidwell    ::   http://www.codesourcery.com   ::     CodeSourcery LLC
nathan@codesourcery.com    ::     http://www.planetfall.pwp.blueyonder.co.uk

Re: RFC: New C++ Attribute: final

[Alexandre Oliva]

On Mar  1, 2004, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:

> Jeff Sturm <jsturm@one-point.com> writes:
> | >  From a programmer's perspective, why is it desirable to remove the
> | > virtuality?
> | 
> | For C++, I can't think of a good reason besides performance.  In Java, I
> | think 'final' is essential to the security framework.

> There is no doubt that people will construct examples where they
> think they need final for C++.

One of them will probably have to do with passing pointers to member
functions to STL algorithms.  There's no way in C++ that I know to
create a pointer to member that doesn't undergo virtual method
dispatch if the named method turns out to be virtual.  Sure you can
introduce a separate private method and not only call it from the
virtual method, but also use it when you need a non-dynamic pointer to
method, but you have to hope nobody ever decides to introduce a
virtual method in a base class using the same name, to enable a
derived class to preempt your wish for a non-virtual pointer to
method.

Not that I personally find the need for non-virtual pointers to
members in good designs.  It's just that, if final is added to C++,
people will probably want to annotate expressions that take the
address of member functions, and from that even function calls as
final!  The horror! :-) :-)

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Happy GNU Year!                     oliva@{lsd.ic.unicamp.br, gnu.org}
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: RFC: New C++ Attribute: final

[Gabriel Dos Reis]

Alexandre Oliva <aoliva@redhat.com> writes:

| On Mar  1, 2004, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:
| 
| > Jeff Sturm <jsturm@one-point.com> writes:
| > | >  From a programmer's perspective, why is it desirable to remove the
| > | > virtuality?
| > | 
| > | For C++, I can't think of a good reason besides performance.  In Java, I
| > | think 'final' is essential to the security framework.
| 
| > There is no doubt that people will construct examples where they
| > think they need final for C++.
| 
| One of them will probably have to do with passing pointers to member
| functions to STL algorithms.

Taking a pointer-to-member is a very *general* mechanism, that comes
with its price.  And in pratice, it is far more efficient (whether the
member function is virtual or not is immaterial) just to use custom
function objects that directly call the function: You get far *better*
efficiency.  
     
|  There's no way in C++ that I know to
| create a pointer to member that doesn't undergo virtual method
| dispatch if the named method turns out to be virtual.  Sure you can

When you create a pointer to member function, the member
function does not need to be virtual, but still you get *much more*
inefficiency (and that is worse if your happens to be GCC). And final
does not help here.  There are well-knwon techniques to write clearer
and more efficient codes:  Use function objects that directly call the
function.  You may even get inlining if the function were inline.  
That is what the STL has been doing :-)

| introduce a separate private method and not only call it from the
| virtual method, but also use it when you need a non-dynamic pointer to
| method, but you have to hope nobody ever decides to introduce a
| virtual method in a base class using the same name, to enable a
| derived class to preempt your wish for a non-virtual pointer to
| method.

People keep damaging codes -- in the name of whatever (usually,
generality).  I believe people  who damage their codes get what they
deserve :-) 

| Not that I personally find the need for non-virtual pointers to
| members in good designs.  It's just that, if final is added to C++,
| people will probably want to annotate expressions that take the
| address of member functions, and from that even function calls as
| final!  The horror! :-) :-)

With the help of final or not, people are going to damage their codes
anyway :-)  

-- Gaby

Re: RFC: New C++ Attribute: final

[Matt Austern]

On Feb 28, 2004, at 6:43 PM, Kevin Atkinson wrote:

>
> I have an idea for a new C++ attribute, and would like to know what 
> others
> think of it:
>
> 'final'
>
> Marks a virtual function of an entire class as being "final", in the 
> sense
> that it can not be overridden in a derived class.  If it is applied to 
> a
> type then every virtual function in the class will be considered final.
> It will not, however, keep a class from being inherited from.
> Gcc will produce a warning (or maybe an error) if a "final" method is
> overridden.
>
> The primary purpose of this attribute is to serve as an optimization 
> hint
> so that a virtual function call does not need to be used.  It will also
> allow gcc to perhaps inline the function call if it is appropriate.

My opinion is that this would be better sent to the C++ standards
committee than to the gcc mailing list.  That is: I would be much
happier if this were part of portable C++ than if we put it in as an
ad hoc extension.

Rationale: our experiences with language-design-by-compiler
have been mixed.  It's unlikely that we'll be able to get all of the
corner cases on a new language feature right if we just say "this
feature should do thus-and-such for this example", because we
have to know what it does for code other than whatever is in a
finite number of examples.  And C++ is a complicated enough
language that a new feature is likely to have corner cases and
non-obvious interactions with other features, even if it seems
simple at first.

			--Matt

Re: RFC: New C++ Attribute: final

[George Garvey]

On Tue, Mar 02, 2004 at 12:57:21PM -0800, Matt Austern wrote:
> My opinion is that this would be better sent to the C++ standards
> committee than to the gcc mailing list.  That is: I would be much

   I believe some of the GCC people are on that committee, although I could
be wrong. Do they get smarter when they attend committee meetings? I always
noticed the opposite effect, myself. But I've never been at a standard
committee.
	The real issue is that it should be done completely, and specified,
which unfortunately has apparently not always been the case with GCC
extensions; so now everyone seems burnt out with them. I'm not giving an
opinion on whether this should be put in GCC. But this particular argument
doesn't make sense.
   It seems like there are some people working on GCC who could design
something like this quite competently. Whether they will, or want to, is
another thing, of course, which is none of my business.

Re: RFC: New C++ Attribute: final

[Alexandre Oliva]

On Mar  2, 2004, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:

> Taking a pointer-to-member is a very *general* mechanism, that comes
> with its price.  And in pratice, it is far more efficient (whether the
> member function is virtual or not is immaterial) just to use custom
> function objects that directly call the function: You get far *better*
> efficiency.  
     
But then you can't use a generic template class to implement this
object, which makes it far more cumbersome.

> When you create a pointer to member function, the member
> function does not need to be virtual

Certainly not.  But if such a pointer to member was final and bound to
a known function, GCC might be able to short-curcuit function calls
through it, and even inline them.  But since, for a virtual function,
it is not possible to know the exact function that is going to be
called unless you happen to know the dynamic type of the object, you
lose.  With final, you'd win.

> People keep damaging codes -- in the name of whatever (usually,
> generality).  I believe people  who damage their codes get what they
> deserve :-) 

> With the help of final or not, people are going to damage their codes
> anyway :-)  

So what do you propose?  Not to use C++?  Not to use any programming
language? :-) :-)

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Happy GNU Year!                     oliva@{lsd.ic.unicamp.br, gnu.org}
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: RFC: New C++ Attribute: final

[Joe Buck]

On Tue, Mar 02, 2004 at 12:57:21PM -0800, Matt Austern wrote:
> My opinion is that this would be better sent to the C++ standards
> committee than to the gcc mailing list.  That is: I would be much
> happier if this were part of portable C++ than if we put it in as an
> ad hoc extension.

I think that anything that we implement should be specified well enough
so that the spec could serve as draft language for an extension to the
standard.  However, given such language, it certainly makes sense to
be able to demonstrate the proposed extension with a working
implementation.  A number of features now present in C99 or ISO C++
were originally GCC extensions, though in many cases the final form
did not quite match the original GCC extension.  Examples include
variable-length arrays in C, and the ability to define class constants
in the class body in C++.  If GCC switches to such a firm anti-extension
policy that such features are not considered in the future, and just
leave language committees to specify new features that have never seen
use, this will harm the quality of future language standards.

So we need to strike a balance.

> Rationale: our experiences with language-design-by-compiler
> have been mixed.  It's unlikely that we'll be able to get all of the
> corner cases on a new language feature right if we just say "this
> feature should do thus-and-such for this example", because we
> have to know what it does for code other than whatever is in a
> finite number of examples.  And C++ is a complicated enough
> language that a new feature is likely to have corner cases and
> non-obvious interactions with other features, even if it seems
> simple at first.

I think that we should not close the door for use of GCC as a testbed,
but we should set a high standard.  In the case of extensions I think
that we should require a document along with any proposed patch, and
have some review of the document before bothering with reviewing the
patch.  The document should be in the form of a proposal to extend the
standard to accept the extension, meaning that it has to address
interactions with other language features.  The proposal doesn't have
to be rock-solid final standardese at the time the patch is accepted, but
it should answer the questions that the reviewers can come up with.

In the case of "final", the good news is that there is a lot of prior
art; in particular, the meaning of "final" in Java, where the keyword can
be applied either to a class or to a member function.  Someone proposing
"final" could start from there, then see if there are any additional
interactions in C++.  I can think of one:

- nonvirtual functions.  If a nonvirtual function is overridden by a
  "final" function in the derived class, should we object?  (This can't
  happen in Java).

Re: RFC: New C++ Attribute: final

[Daniel Berlin]

> Certainly not.  But if such a pointer to member was final and bound to
> a known function, GCC might be able to short-curcuit function calls
> through it, and even inline them.  But since, for a virtual function,
> it is not possible to know the exact function that is going to be
> called unless you happen to know the dynamic type of the object, you
> lose.  With final, you'd win.
>

Compilers besides GCC have started to get good at determining the 
dynamic types of objects and "devirtualizing calls".  Some also 
implement more trivial methods (see if it must-alias a certain 
component of the virtual table object, and thus, must be pointing to 
that call) as a backup.
It's somewhere down on my list to implement some form of analysis 
(RTA/CHA/whatever) to be able to a determine a small set of actual 
calls a given virtual call can make.
No clue when i'll get to it. Probably around the same time we start 
doing other IPA things.

Re: RFC: New C++ Attribute: final

[Richard Henderson]

On Tue, Mar 02, 2004 at 06:24:48PM -0500, Daniel Berlin wrote:
> It's somewhere down on my list to implement some form of analysis 
> (RTA/CHA/whatever) to be able to a determine a small set of actual 
> calls a given virtual call can make.

We'll want to adjust the IL to make this easier for you.  For
instance, use a METHOD_CALL_EXPR instead of a CALL_EXPR with
the vtable lookup junk pre-expanded.  Or something.


r~

Re: RFC: New C++ Attribute: final

[Dale Johannesen]

On Mar 2, 2004, at 4:09 PM, Richard Henderson wrote:
> On Tue, Mar 02, 2004 at 06:24:48PM -0500, Daniel Berlin wrote:
>> It's somewhere down on my list to implement some form of analysis
>> (RTA/CHA/whatever) to be able to a determine a small set of actual
>> calls a given virtual call can make.
>
> We'll want to adjust the IL to make this easier for you.  For
> instance, use a METHOD_CALL_EXPR instead of a CALL_EXPR with
> the vtable lookup junk pre-expanded.  Or something.

There are wins to be had by analyzing indirect calls in C,
also, for example on the gap SPECmark.  What you want to do there is
find the hot indirect calls and the hot calls that actually get made 
via feedback,
and pull out the common cases and inline them.

Re: RFC: New C++ Attribute: final

[Alexandre Oliva]

On Mar  2, 2004, Daniel Berlin <dberlin@dberlin.org> wrote:

>> Certainly not.  But if such a pointer to member was final and bound to
>> a known function, GCC might be able to short-curcuit function calls
>> through it, and even inline them.  But since, for a virtual function,
>> it is not possible to know the exact function that is going to be
>> called unless you happen to know the dynamic type of the object, you
>> lose.  With final, you'd win.

> Compilers besides GCC have started to get good at determining the
> dynamic types of objects and "devirtualizing calls".

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.  There's no way to express this in C++ other than
introducing another function, member or friend, that calls the
function using a qualified name.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Happy GNU Year!                     oliva@{lsd.ic.unicamp.br, gnu.org}
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: RFC: New C++ Attribute: final

[Alexandre Oliva]

On Mar  2, 2004, Joe Buck <Joe.Buck@synopsys.COM> wrote:

> So we need to strike a balance.

How about: experimental extensions must only be enabled if a certain
flag is given in the command line?  Like that of signatures, just to
mention an example of an extension that didn't go forward.  Then we
still serve as a testbed, but we don't have backward-compatibility
issues to worry about.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Happy GNU Year!                     oliva@{lsd.ic.unicamp.br, gnu.org}
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: RFC: New C++ Attribute: final

[Richard Henderson]

On Tue, Mar 02, 2004 at 04:21:44PM -0800, Dale Johannesen wrote:
> There are wins to be had by analyzing indirect calls in C,
> also, for example on the gap SPECmark.  What you want to do there is
> find the hot indirect calls and the hot calls that actually get made 
> via feedback, and pull out the common cases and inline them.

Yes, but that's irrelevant to matching up CALL_EXPR with
"type of object being called", and thence to "which function
must be invoked".

Basically, we'd rather not hard-code vtable layout specifics
in the language-independant optimizer.  What we'd rather do
is deduce the object being referenced, then pass the whole
mass back to the language and say "hey, can you guess what's
going on here?"

Given that, I'd think

	<METHOD_CALL_EXPR
		<object expression>
		<lang-specific method token>>
		<args>>

is easier to manipulate than

	<CALL_EXPR
		<addr_expr <function_decl>>
		<args>>

and then you have to pull out the object from the first or
second argument of the list, depending on the signature of
the function.



r~

Re: RFC: New C++ Attribute: final

[Dale Johannesen]

On Mar 2, 2004, at 4:33 PM, Richard Henderson wrote:
> On Tue, Mar 02, 2004 at 04:21:44PM -0800, Dale Johannesen wrote:
>> There are wins to be had by analyzing indirect calls in C,
>> also, for example on the gap SPECmark.  What you want to do there is
>> find the hot indirect calls and the hot calls that actually get made
>> via feedback, and pull out the common cases and inline them.
>
> Yes, but that's irrelevant to matching up CALL_EXPR with
> "type of object being called", and thence to "which function
> must be invoked".

Certainly the problems are different, but there's some similarity and
some of the code could be shared, if whoever does it is thinking
along those lines.  That's all I meant to suggest at this point.

Re: RFC: New C++ Attribute: final

[Gabriel Dos Reis]

Alexandre Oliva <aoliva@redhat.com> writes:

| On Mar  2, 2004, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:
| 
| > Taking a pointer-to-member is a very *general* mechanism, that comes
| > with its price.  And in pratice, it is far more efficient (whether the
| > member function is virtual or not is immaterial) just to use custom
| > function objects that directly call the function: You get far *better*
| > efficiency.  
|      
| But then you can't use a generic template class to implement this
| object, which makes it far more cumbersome.

The function is certainly not generic, so what is the problem?

| > When you create a pointer to member function, the member
| > function does not need to be virtual
| 
| Certainly not.  But if such a pointer to member was final and bound to

But, the pointer to member is a *constant*, in a given scope with
defined lifetime.  That GCC does not take advantage of that is another
problem. 

| a known function, GCC might be able to short-curcuit function calls
| through it, and even inline them.

But we already have concrete situations with all the implied semantics
constraints and yet GCC fails to to do proper job.  Local class.

I'm not saying final is bad, I'm merely pointing out that facts.

| But since, for a virtual function,
| it is not possible to know the exact function that is going to be
| called unless you happen to know the dynamic type of the object, you
| lose.  With final, you'd win.
| 
| > People keep damaging codes -- in the name of whatever (usually,
| > generality).  I believe people  who damage their codes get what they
| > deserve :-) 
| 
| > With the help of final or not, people are going to damage their codes
| > anyway :-)  
| 
| So what do you propose?

Education :-) 

| Not to use C++? 

You don't need C++; it is just a useful tool :-) 
You can write useful software in other programming languages; you can
damage codes in other programming languages too.

| Not to use any programming language? :-) :-)

Stroustrup has an interesting chapter on "what programming at all?" in
his third edition :-)


Don't try to put in me in the camp of the "anti-final"s ;-/

-- Gaby

Re: RFC: New C++ Attribute: final

[Gabriel Dos Reis]

Alexandre Oliva <aoliva@redhat.com> writes:

| On Mar  2, 2004, Daniel Berlin <dberlin@dberlin.org> wrote:
| 
| >> Certainly not.  But if such a pointer to member was final and bound to
| >> a known function, GCC might be able to short-curcuit function calls
| >> through it, and even inline them.  But since, for a virtual function,
| >> it is not possible to know the exact function that is going to be
| >> called unless you happen to know the dynamic type of the object, you
| >> lose.  With final, you'd win.
| 
| > Compilers besides GCC have started to get good at determining the
| > dynamic types of objects and "devirtualizing calls".
| 
| 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?  ;-)

| There's no way to express this in C++ other than
| introducing another function, member or friend, that calls the
| function using a qualified name.

Yes, but we need to (1) audit how good we already are at issue the
"final" semantics implied current situations (we're near zero)
(2) how much of type information do we use (we're near zero, but I
hope the situation will get better with tree-ssa).  
And we're shouting for a new keyword.  Before you call me a rigid guru,
please try to understand that

  (1) I'm not anti- nor pro- final, at this stage;
  (2) understand the other factors and points.

-- Gaby
 

Re: RFC: New C++ Attribute: final

[Gabriel Dos Reis]

George Garvey <tmwg-gcc@inxservices.com> writes:

| On Tue, Mar 02, 2004 at 12:57:21PM -0800, Matt Austern wrote:
| > My opinion is that this would be better sent to the C++ standards
| > committee than to the gcc mailing list.  That is: I would be much
| 
|    I believe some of the GCC people are on that committee, although I could
| be wrong. Do they get smarter when they attend committee meetings? I always
| noticed the opposite effect, myself. But I've never been at a standard
| committee.

Isn't there any campaign to "guide" those people not being GCC people
anymore? 

-- Gaby

Re: RFC: New C++ Attribute: final

[Joe Buck]

On Wed, Mar 03, 2004 at 01:42:42AM +0100, Gabriel Dos Reis wrote:
> But, the pointer to member is a *constant*, in a given scope with
> defined lifetime.  That GCC does not take advantage of that is another
> problem. 

Consider this testcase:

----------------------------------------------------
#include <functional>
#include <string>
#include <iterator>
#include <vector>
#include <iostream>

int main() {
    std::vector<std::string> words;
    words.push_back("one");
    words.push_back("two");
    words.push_back("three");
    std::transform(words.begin(),
		   words.end(),
		   std::ostream_iterator<size_t>(std::cout, "\n"),
		   std::mem_fun_ref(&std::string::length));
}
----------------------------------------------------

Here we have a pointer to member function that is a constant: this
program writes the lengths of the words in the words array to standard
out.  And sure enough, with -O2, GCC 3.3.3 doesn't leave any indirect
or direct call to std::string::length around.

Re: RFC: New C++ Attribute: final

[Alexandre Oliva]

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}

Re: RFC: New C++ Attribute: final

[Gabriel Dos Reis]

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

Re: RFC: New C++ Attribute: final

[Gabriel Dos Reis]

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

| On Wed, Mar 03, 2004 at 01:42:42AM +0100, Gabriel Dos Reis wrote:
| > But, the pointer to member is a *constant*, in a given scope with
| > defined lifetime.  That GCC does not take advantage of that is another
| > problem. 
| 
| Consider this testcase:


    struct A {
       int f() { return 7; }
    };

    template<class T>
    inline int
    apply(A* p, T f)
    {
       return (p->*f)();
    }

    int main()
    {
       A tab[20];
       for (int i = 0; i < 20; ++i)
          apply(tab + i, &A::f);
    }


[...]

| out.  And sure enough, with -O2, GCC 3.3.3 doesn't leave any indirect
| or direct call to std::string::length around.

Look carefully at the assembly generated.

-- Gaby

Re: RFC: New C++ Attribute: final

[Alexandre Oliva]

On Mar  3, 2004, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:

> I believe you completely missed what I was saying.

No.  You're just thinking of a completely different issue.  I'm
talking about a case that can't possibly be optimized by GCC without
an extension, because the optimization would be wrong.  You're
pointing out cases in which GCC fails to apply an optimization that
would be correct.  Both are related with turning virtual calls into
direct calls, but they're not the same.

-- 
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}

Re: RFC: New C++ Attribute: final

[Gabriel Dos Reis]

Alexandre Oliva <aoliva@redhat.com> writes:

| On Mar  3, 2004, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:
| 
| > I believe you completely missed what I was saying.
| 
| No.  You're just thinking of a completely different issue.  I'm
| talking about a case that can't possibly be optimized by GCC without
| an extension, because the optimization would be wrong.  You're
| pointing out cases in which GCC fails to apply an optimization that
| would be correct.  Both are related with turning virtual calls into
| direct calls, but they're not the same.

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.
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.

-- Gaby

Re: RFC: New C++ Attribute: final

[Joe Buck]

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.

Re: RFC: New C++ Attribute: final

[Gabriel Dos Reis]

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,

The issue is actually type rooted.  Given C++ separate compilation,
you would need a way to make the callee agree on the type of that
expression so that it expands to the "right" function, or else you get
th wrong result.  Someone was worrying about safety, I don't think
this one is making us move towards that direction.


-- Gaby

Re: RFC: New C++ Attribute: final

[Robert Dewar]

> How about: experimental extensions must only be enabled if a certain
> flag is given in the command line?  Like that of signatures, just to
> mention an example of an extension that didn't go forward.  Then we
> still serve as a testbed, but we don't have backward-compatibility
> issues to worry about.

The switch -gnatX acts this way for Ada, and is currently being used
to enable tentatively approved extensions for Ada0Y (the next version
of Ada).

Re: RFC: New C++ Attribute: final

[Chris Lattner]

> 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.

Speaking from the perspective of a developer that writes a lot of C++
code, I totally agree with your viewpoint.  There _are_ workarounds that
don't cause code duplication (in the derived class, have a non-virtual
method do the work, and have the virtual one just call it), but these are
really gross and seemingly against the spirit of C++.

Also, it's not feasible to make all of the clients know about this
distinction, and if it changes over time, it's not scalable to modify tons
of client code where we could just modify one declaration in the header.
Also, if the client code is really a template using std::mem_fun or
something, it's not *possible* to change the client (without even more
gross hacks I suppose).

In my situation, I have complete control over the class hierarchy and if a
new subclass needs to be added, it's ok to remove the attribute and force
clients to recompile.  Though not everyone is in this situation, many are,
and it seems very reasonable to support it directly: even as a GCC
extension.

-Chris

-- 
http://llvm.cs.uiuc.edu/
http://www.nondot.org/~sabre/Projects/

RE: RFC: New C++ Attribute: final

[Cheng, Cheuk]

Hi, I am using sparc-elf-gcc 2.9.5.3.  Does the virtual destructor in
the 00000000 <__._1B>: portion below actually call the destructor for
the parent class A?  Or is it calling ___builtin_delete() when it says
something like this?

00000004 <.LM10>:
   4:	11 00 00 00 	sethi  %hi(0), %o0
			4: R_SPARC_HI22	___vt_1A
   8:	90 12 20 00 	mov  %o0, %o0	! 0 <__._1B>
			8: R_SPARC_LO10	___vt_1A
   c:	d0 26 20 08 	st  %o0, [ %i0 + 8 ]
  10:	40 00 00 00 	call  10 <.LM10+0xc>
			10: R_SPARC_WDISP30	___builtin_delete
  ...............
  <full version follows source code below>

When I compile the same source code without any optimizations (-O1, -O2,
etc.) , then I can see a call to A::~A instead of ___builtin_delete().
Since I do not know sparc assembly language, I do not know whether the
object code generated is right or not.

Thanks.



class A
{
public:
	A() { X = 0; Z = new(char); }
	A(int temp) : X(temp) { Z = new(char); }
	virtual ~A() { delete Z; }

private:
	int	 X;
	char *Z;
};

class B: public A
{
public:
	B() : A(1), Y(2) {}
	~B() {}

private:
	int	Y;
};

int main(int argc, char **argv)
{
	B	*obj = new B();

	delete obj;

	return 0;
}

====================================================

dstr.o:     file format elf32-sparc

SYMBOL TABLE:
00000000 l    df *ABS*	00000000 dstr.cpp
00000000 l    d  .text	00000000 
00000000 l    d  .data	00000000 
00000000 l    d  .bss	00000000 
00000000 l    d  .gnu.linkonce.d.__vt_1B	00000000 
00000000 l    d  .gnu.linkonce.d.__vt_1A	00000000 
00000000 l    d  .gnu.linkonce.t._._1B	00000000 
00000000 l       .gnu.linkonce.t._._1B	00000000 .LM9
00000004 l       .gnu.linkonce.t._._1B	00000000 .LM10
0000002c l       .gnu.linkonce.t._._1B	00000000 .LM11
00000000 l    d  .gnu.linkonce.t._._1A	00000000 
00000000 l       .gnu.linkonce.t._._1A	00000000 .LM12
00000000 l       *ABS*	00000000 *ABS*
00000000 l    d  .stab	00000000 
00000000 l    d  .stabstr	00000000 
00000000 l    d  .comment	00000000 
00000000 g     F .text	00000064 _main
00000000         *UND*	00000000 ___builtin_new
00000000  w    O .gnu.linkonce.d.__vt_1A	0000000c ___vt_1A
00000000  w    O .gnu.linkonce.d.__vt_1B	0000000c ___vt_1B
00000000  w    F .gnu.linkonce.t._._1B	00000034 __._1B
00000000  w    F .gnu.linkonce.t._._1A	00000034 __._1A
00000000         *UND*	00000000 ___builtin_delete


Disassembly of section .text:

00000000 <_main>:
   0:	9d e3 bf 98 	save  %sp, -104, %sp
   4:	40 00 00 00 	call  4 <_main+0x4>
			4: R_SPARC_WDISP30	___builtin_new
   8:	90 10 20 10 	mov  0x10, %o0
   c:	b0 10 00 08 	mov  %o0, %i0
  10:	92 10 20 01 	mov  1, %o1
  14:	11 00 00 00 	sethi  %hi(0), %o0
			14: R_SPARC_HI22	___vt_1A
  18:	90 12 20 00 	mov  %o0, %o0	! 0 <_main>
			18: R_SPARC_LO10	___vt_1A
  1c:	d0 26 20 08 	st  %o0, [ %i0 + 8 ]
  20:	d2 26 00 00 	st  %o1, [ %i0 ]
  24:	40 00 00 00 	call  24 <_main+0x24>
			24: R_SPARC_WDISP30	___builtin_new
  28:	90 10 20 01 	mov  1, %o0
  2c:	d0 26 20 04 	st  %o0, [ %i0 + 4 ]
  30:	11 00 00 00 	sethi  %hi(0), %o0
			30: R_SPARC_HI22	___vt_1B
  34:	92 12 20 00 	mov  %o0, %o1	! 0 <_main>
			34: R_SPARC_LO10	___vt_1B
  38:	d2 26 20 08 	st  %o1, [ %i0 + 8 ]
  3c:	90 10 20 02 	mov  2, %o0
  40:	80 a6 20 00 	cmp  %i0, 0
  44:	02 80 00 06 	be  5c <_main+0x5c>
  48:	d0 26 20 0c 	st  %o0, [ %i0 + 0xc ]
  4c:	d4 02 60 08 	ld  [ %o1 + 8 ], %o2
  50:	90 10 00 18 	mov  %i0, %o0
  54:	9f c2 80 00 	call  %o2
  58:	92 10 20 03 	mov  3, %o1
  5c:	81 c7 e0 08 	ret 
  60:	91 e8 20 00 	restore  %g0, 0, %o0
Disassembly of section .data:
Disassembly of section .gnu.linkonce.d.__vt_1B:

00000000 <___vt_1B>:
	...
			8: R_SPARC_32	__._1B
Disassembly of section .gnu.linkonce.d.__vt_1A:

00000000 <___vt_1A>:
	...
			8: R_SPARC_32	__._1A
Disassembly of section .gnu.linkonce.t._._1B:

00000000 <__._1B>:
   0:	9d e3 bf 98 	save  %sp, -104, %sp

00000004 <.LM10>:
   4:	11 00 00 00 	sethi  %hi(0), %o0
			4: R_SPARC_HI22	___vt_1A
   8:	90 12 20 00 	mov  %o0, %o0	! 0 <__._1B>
			8: R_SPARC_LO10	___vt_1A
   c:	d0 26 20 08 	st  %o0, [ %i0 + 8 ]
  10:	40 00 00 00 	call  10 <.LM10+0xc>
			10: R_SPARC_WDISP30	___builtin_delete
  14:	d0 06 20 04 	ld  [ %i0 + 4 ], %o0
  18:	80 8e 60 01 	btst  1, %i1
  1c:	02 80 00 04 	be  2c <.LM11>
  20:	01 00 00 00 	nop 
  24:	40 00 00 00 	call  24 <.LM10+0x20>
			24: R_SPARC_WDISP30	___builtin_delete
  28:	90 10 00 18 	mov  %i0, %o0

0000002c <.LM11>:
  2c:	81 c7 e0 08 	ret 
  30:	81 e8 00 00 	restore 
Disassembly of section .gnu.linkonce.t._._1A:

00000000 <__._1A>:
   0:	9d e3 bf 98 	save  %sp, -104, %sp
   4:	11 00 00 00 	sethi  %hi(0), %o0
			4: R_SPARC_HI22	___vt_1A
   8:	90 12 20 00 	mov  %o0, %o0	! 0 <__._1A>
			8: R_SPARC_LO10	___vt_1A
   c:	d0 26 20 08 	st  %o0, [ %i0 + 8 ]
  10:	40 00 00 00 	call  10 <__._1A+0x10>
			10: R_SPARC_WDISP30	___builtin_delete
  14:	d0 06 20 04 	ld  [ %i0 + 4 ], %o0
  18:	80 8e 60 01 	btst  1, %i1
  1c:	02 80 00 04 	be  2c <__._1A+0x2c>
  20:	01 00 00 00 	nop 
  24:	40 00 00 00 	call  24 <__._1A+0x24>
			24: R_SPARC_WDISP30	___builtin_delete
  28:	90 10 00 18 	mov  %i0, %o0
  2c:	81 c7 e0 08 	ret 
  30:	81 e8 00 00 	restore 


- - - - - - - Appended by PowerTV, Inc. - - - - - - - 
This e-mail and any attachments may contain information that is confidential, proprietary, privileged or otherwise protected by law. The information is solely intended for the named addressee (or a person responsible for delivering it to the addressee). If you are not the intended recipient of this message, you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete it from your computer.