Re: Never ever use a raw pointer when a smart pointer can do the same
job
On Aug 21, 12:59 am, Noah Roberts <roberts.n...@gmail.com> wrote:
Noah Roberts wrote:
Alf P. Steinbach wrote:
A self deleting object is one that will respond to some
function calls by calling "delete this". Example:
struct self_deleter { void do_something() { delete this; }};
The fact that it will do this requires that this object always
be created by a call to new. Note that there is no way for
the object to know how it was created unless it enforces that
method so it can't conditionally delete based on how it was
created.
The above class is badly design because it can be used
incorrectly. Your class advertises an interface that is
inappropriate for its use: namely it can be created on the
stack as a local variable. Any such use though will evoke
serious derangement in the program which will most likely
exhibit itself by a hard crash...as in the program just
disappears on the user.
The class that Alf proposed can't be created on the stack or as
a static variable, except in class members or derived class
members, since it's destructor is protected. When declaring a
variable, the destructor must be accessible at the point of
declaration.
But perhaps more to the point---you can misuse classes which do
delete this. You can misuse any class, if you really want to.
The question is rather "what is the risk that a reasonable
programmer would do so." I often derive (publicly) from
std::iterator, for example, when I define my own iterator.
std::iterator doesn't have a virtual destructor, nor is the
destructor protected, so client code can easily delete through a
pointer to the std::iterator base, causing undefined behavior.
Do I worry about this? No, because I consider the probability
of that happening in code written by a reasonable programmer to
be almost 0. There's just no reason for a reasonable programmer
to ever have a pointer to std::iterator.
Similarly, most application level classes tend to fall into two
categories: those which are always allocated dynamically, and
have explicitly managed lifetimes, and those which are never
allocated dynamically. There are obviously exceptions, but they
aren't that frequent, and the "delete this" idiom applies
exclusively to the first category. Classes which based on their
overall semantics make no sense allocated other than
dynamically. By definition---if a class has a managed lifetime,
and should be destructed in response to an external event, then
it can't be used in contexts where the destruction is
"pre-programmed" independently of that event. The delete this
issue is, in fact, completely irrelevant.
Why wouldn't you leave this up to documentation and developer
know-how?
You could...if you could make sure everyone A) read all the
documentation, B) could remember everything they've read, and
C) never made a mistake and assumed that because a function is
there to BE called that it can be called. The steps required
to protect the user (often yourself) are minimal so really the
question is, why WOULD you leave this up to documentation and
developer know-how?
Because, like so many other things, you have to. Again, whether
the class uses delete this, or the delete is managed by a
transaction, or whatever, really isn't relevant. A programmer
cannot successfully use a class unless he knows at least the
basics of what the class does, and what it's purpose is. If the
role of the class requires a managed lifetime, then the
programmer can't use the class successfully without knowing
this. The name of the class will often give a strong hint, but
in the end, some documenation will probably be necessary. And a
programmer who uses a class without reading the documentation,
on the odd chance that it might do something useful in his case,
is a programmer who doesn't last long.
--
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