Re: Never ever use a raw pointer when a smart pointer can do the same
job
On Aug 17, 5:46 pm, Noah Roberts <roberts.n...@gmail.com> wrote:
Yannick Tremblay wrote:
In article <7em6k0F2cs2o...@mid.individual.net>,
Ian Collins <ian-n...@hotmail.com> wrote:
James Kanze wrote:
They're not that useful. Typically, an object which
reacts to an event which terminates its lifetime will
either do a delete this, or it will register with the
current transaction, which will delete it in the commit.
I don't see where smart pointers would play much of a role
here---in the case of "delete this", "this" can't be a
smart pointer.
James, I think your "Typically," is the cause of most of
the misunderstanding on this thread.
The idiom you describe isn't one I have used, I don't think
I have ever written "delete this" in anger. My typical
scenario is an object is created, it gets placed in a
container for later processing and it gets erased from the
container once it has been processed.
In that scenario, a reference counted smart pointer is the
easiest way to manage the lifetime of the object.
I have written "delete this" but I certainly would not
classify it as typical either. Certainly, some specific
problems can have a very elegant solution using "delete
this" but I see it as one possible solution to limited set
of situations.
And I've seen it used too much and debugged too much code that
used it. MUCH care need be taken when you do a delete this.
For one, you better have that constructor protected so naive
coders don't think it's part of the public interface and just
try to use it.
I suspect that there's a typo in there somewhere---you *never*
use delete this in a constructor. For the rest, delete this
doesn't require more care than any other delete. Regardless of
where the delete comes from, you have to ensure that all other
concerned parties are notified.
In general, I don't like the idea of an object being
responsible for its own lifetime.
I'd consider it a fundamental concept of OO---an object has
behavior, and if the behavior required for a specific message is
to terminate the object's lifetime, delete this seems to me the
simplest, clearest and most easily understood means of doing so.
There are obviously many cases where it is not
appropriate---transactions come to mind (where the "termination"
may have to be rolled back), or GUI code with separation of view
and model (where the model treats the event, and terminates the
lifetime of the view). But there are just as many where it is
appropriate.
There are always exceptions to any general rule, so before the
pedants tear into me for saying so: yes, there are exceptions.
In general though, an object should have one responsibility
only and if all an object is responsible for is its own
lifetime...then it has no reason to exist.
:-).
An object is responsible for handling events which concern it;
if the event which concerns it calls for its deletion, who
better to do the delete. An object is responsible for managing
its state; whether it exists or not is part of its state.
And so on. In practice, each application is a case of its own,
and the decision will depend in many ways on the structure of
your code. There are certainly a lot of situations where delete
this is not appropriate---generally more or less for the reason
you mentionned (e.g. a GUI object generally won't handle its
events directly, since its responsibility is managing the
display; it will pass them on to an event handler, which will
delete the GUI object---and perhaps indirectly itself, since
it's quite conceivable that the GUI object delete all of the
event handlers it owns in its destructor).
Anyway, I won't insist too much on the delete this, since it
really is incidental. The point is that somewhere, someone will
want to delete the object explicitly, in reaction to an external
event, and that in many cases, the pointer that that someone has
will derive from the this pointer of the object (and smart
pointers which don't work if you create new instances from the
this pointer, like boost::shared_ptr, are simply banned in
projects where I have a say).
--
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