Re: virtual fn, destructor
On Dec 17, 10:11 pm, "DavidW" <n...@email.provided> wrote:
Pete Becker wrote:
On 2008-12-16 18:42:22 -0500, "DavidW" <n...@email.provided> said:
Pete Becker wrote:
On 2008-12-16 15:45:47 -0500, "DavidW" <n...@email.provided> said:
[...]
My documentation is a text presentation that, among other
things, documents the design decision: don't delete derived
types through a pointer to my class. A protected destructor
is code, not documentation. A comment is code, not
documentation.
Unless you're using Doxygen:-).
Seriously, there should be a relationship between the comments
and the code. And there's nothing wrong with enforcing the
contract, when feasable; if the contract says that client code
should not destruct instances of the object (only reasonable if
all instances are allocated dynamically), then declaring the
destructor protected (or private, if you're not supporting
inheritance) seems correct, just as it would be for any other
function. (Surely, Pete, you're not saying that we shouldn't
use private and public, because the documentation should be
enough.)
It's not my job to "enforce" design decisions that I've
made. It's the user's job to understand the class well
enough to use it correctly. Programmers who don't bother to
read documentation aren't really programmers, just warm
bodies filling seats.
That may be, but if your aim is to have the highest possible
standard of software in the world, then documentation alone
won't do, since it's a statistical certainty that there will
be programmers - sorry, warm bodies filling seats who write
programs - who will ignore it.
That's why you have code reviews. Such programmers will either
change their ways, or won't be allowed to work on code.
When feasable, I'm all in favor of using both suspenders and a
belt: document the restrictions, and implement the code such
that violating them causes a compiler error. But it's not
always feasable, and making the destructor protected has
additional impact which has to be considered. If it has no
extra cost, fine, but otherwise, you have to weigh the costs.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34