Daniel T. wrote:
"Noah Roberts" <ro**********@gmail.comwrote:
I am trying to pull behavior out of a class so that the class can be
replaced. Part of that behavior takes place in the destructor of the
object. I need call sites to change so that they call a cleaner
function and then let the object get deleted normally.
Any good ideas on a nice approach? Best I can seem to come up with is
to privatize the destructor and let the compiler complain. Problem is
that it goes a little insain and I think comes up with a lot of false
positives...or extra locations...
That's a tough one. If you make the d_tor private, the compiler will
complain at object construction, if you remove the d_tor the compiler
will provide one. :-(
Unless the objects of this class are always newed and deleted, I
question the wisdom of removing the class RAII demands the object exist.
I'd say do one of two things, either refactor the class itself so that
the default d_tor is adequate (effectively removing the need to refactor
the d_tor directly,) or comment out Class* declarations to flush out all
the "delete object" references where 'object' is of type Class* and put
your new function just above each delete.
I'm going to cut this corner. The principles surrounding refactoring
say you should refactor one step at a time but in this case I will need
to do two. I'm working on removing an invasive list structure that has
caused long years of feature creep in unrelated but sibling classes. I
want to make it look and act like any old stl adt but this one owns its
pointers....deletes them when it is destroyed and such.
I'm going to have to switch ADT and pointer type at the same time so
that I make the switch to STL containers and use shared_ptr
simultaneously hoping that they come close to behavior enough to make
it work. Obviously anywhere that this list deleted its pointers will
also hapen with shared_ptrs (assuming they aren't kept elsewhere), and
anywhere that is holding raw copies still needs to be sure that the
list exists so there should be little trouble. Unfortunately I'm in a
legacy situation and have no harness...
I thought maybe I could privatize the destructor and call a destroy
function on the class (that would necissarily have to be a
friend)...unfortunately the primary use of this class is stack based so
that's out. I'm kind of painted into a corner but I think I can weazel
my way out.