This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: RFC: New C++ Attribute: final
- From: Gabriel Dos Reis <gdr at integrable-solutions dot net>
- To: Joe Buck <Joe dot Buck at synopsys dot COM>
- Cc: Nathan Sidwell <nathan at codesourcery dot com>, Kevin Atkinson <kevina at gnu dot org>, Mark Mielke <mark at mark dot mielke dot cc>, gcc at gcc dot gnu dot org
- Date: 01 Mar 2004 19:46:55 +0100
- Subject: Re: RFC: New C++ Attribute: final
- Organization: Integrable Solutions
- References: <Pine.LNX.4.44.0402290149380.30657-100000@kevin-p3.atkinson.dhs.org><40430E61.7000205@codesourcery.com><20040301104453.D28871@synopsys.com>
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