Re: Rewriting clone() to return a boost::shared_ptr ?
helix wrote:
I can see how changing clone() to use smart pointers would
violate the usual standard conventions, as well as causing
confusion to other developers. Would you be happier if I
provided two clone functions, one which returns a standard
pointer and another which returns a smart pointer?
I can imagine cases where that might be appropriate. I think
the real question boils down to what the role of the object is
in the application, and why it is supporting clone(). If the
reason clone is being provided is to support transactions, for
example (so that you can roll back if necssary), it makes
absolutely no sense to return any smart pointer, in general.
As for auto_ptr, I generally stay well away as I can't store
them in STL containers. IMHO this single fact renders it
impractical in the real world - especially when you have
boost's superior smart pointers available to you. I have to
confess that I rarely use raw pointers any more, relying
almost entirely on boost's smart pointers.
I tried that, and it didn't work. In my applications, most of
the dynamically allocated objects are entity objects, with
explicitly managed lifetimes. If all I counted on were boost's
smart pointers, I'd need to add some special function, like
dispose, to terminate the object lifetime, and deal with zombie
objects. And once I've added the necessary logic to ensure that
all other concerned objects are correctly notified when the
object's lifetime ends, a smart pointer doesn't add anything
except extra complications; IMHO, in such cases, it is much
easier to simply do "delete this" in the object function which
detects the condition, and use the destructor to propagate
notification. The equivalent using Boost would probably be to
maintain all of the objects in a collection (generally necessary
anyway), with a shared_ptr in the collection, and weak_ptr every
where else. To me, "delete this" just seems simpler and more
explicit that removing the object from the collection, and
counting on the side effect of removing it to call delete.
As for auto_ptr, it's true that you cannot put it in a standard
container. But it is very useful for managing the transition
between the moment you create the object, and the moment you've
transfered the object to whatever is responsible for managing
it. Dave Abrahams posted that using auto_ptr was a more
responsible approach, and I rapidly (too rapidly) posted a
counter argument -- the more I think about it, the more I think
he's right. When you don't know -- and don't want to know --
the actual mechanism handling lifetime, auto_ptr is the correct
transitional solution. In my example using transactions,
there's absolutely no reason to use smart pointers in general;
the transaction has to manage the pointers anyway, which objects
get deleted, and whether anything has to be done with them
before the delete, depends on whether the transaction has been
committed or not. But there is a small window of time between
the moment the copy has been created, and the moment the
transaction manager has effectively put it where ever it has to
be so that the destructor will find it correctly -- the
operation is not atomic. Some of the time, there will be no
possibility of an exception in that window of time, and the
auto_ptr doesn't serve any useful purpose. But Dave is right:
why worry about it? (And if the transaction manager is saving
the pointers in a standard container, a bad_alloc is always
possible -- unless you've installed a new_handler which aborts.)
If you do want to use boost::shared_ptr to manage the object, of
course, it has a constructor which takes an auto_ptr, so there's
no problem.
--
James Kanze GABI Software
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]