I am curious as to why there is little discussion of the possibility
of a Java-style "final" keyword for C++.  I believe that it could
add some additional security to the language at a reasonably small
addition to compilers.

There are several uses for "final" in Java, and I'm only interested in
some of them.

   (1) "final" data cannot be changed.
   (2) "final" member functions cannot be overridden.
   (3) "final" classes cannot be extended (derived).

Clearly, (1) is already available with "const".  However, I do not
believe that (2) or (3) can be implemented.  If I am incorrect,
I would be glad to hear how this can be done without any changes
to the language.

Why are these useful?  One important reason for (3) is that it
prevents problems with destructors.  If one can prevent inheritance
from class A, then A can have a non-virtual destructor.  This can be
important for small classes, particularly to avoid the overhead of a
vtable pointer.  In fact, many programmers choose to use non-virtual
destructors, trusting that no one will derive any children.  This
method seems risky, especially for long-term, maintainable code.  By
declaring a class "final", there would be less risk.  I believe that
there are other examples of the benefits of (3).

(2) is also significant, but I have found no real need for it
personally.  However, compilers could enable a warning for overriding
of a non-virtual function.  With such a diagnostic, there would be
less need for a hard requirement.  I know of no compilers that make
this available.

Perhaps I am merely demonstrating peculiarities of the compilers I
use.  A compiler could generate a diagnostic for derivation from a
class with a nonvirtual destructor or warn about (2).  However, I know
of no compilers that do this (checked HP CC, IRIX CC, g++).

Is there a good reason why these capabilities are unnecessary or
redundant?  If not, shouldn't we either add a construct to support
this or else deprecate the practices so compilers will be encouraged
to warn about them?  Or are they already?


--
   Preston Pfarner
   mailto:presto@gg.caltech.edu
   http://www.gg.caltech.edu/~presto/
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

presto@haggard.gg.caltech.edu (Preston Pfarner) wrote:
>I am curious as to why there is little discussion of the possibility
>of a Java-style "final" keyword for C++.  ...
>   ...
>   (3) "final" classes cannot be extended (derived).
>
>... One important reason for (3) is that it
>prevents problems with destructors.  If one can prevent inheritance
>from class A, then A can have a non-virtual destructor.  ...

Stroustrup discusses this in the D&E:

    A private destructor also prevents derivation. ...
    [p.238]

    Later, Andrew Koenig discovered that it was even possible to prevent
    derivation without imposing restrictions on the kind of allocation that
    could be done....  [Declare a class that derives from a class that has
    a private constructor.]  This relies on the rule that a derived class
    must call the constructor of the base class (implicitly or explicitly).
    [p.239]

He also wrote:

    Such examples are usually more of an intellectual delight than techniques
    of real importance.  Maybe that's why discussing them is so popular.
    [p.239]

-- David R. Tribble, david.tribble@central.beasys.com --
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]