Hi Valery, hi Jonathan, hi Rooters,
> There is a fairly extensive literature on reference-counted objects (and
> smart pointers). I would recommend Scott Myers's discussion in Effective
> C++ and also the implementation in the Visualization Toolkit
> (http://www.kitware.com/vtk and the discussion of these in the
> Visualization Toolkit book by W. Schroeder, B. Lorensen, and K. Martin) as
> good starting points. I think James Coplein discussed this in Advanced C++
> Idioms, but it's been a while since I've read that and I can't remember the
> details of his treatment.
>
> This pattern is perhaps orthogonal to your problem (deleting all references
> upon object destruction), but would at least prevent deleting or destroying
> an object while there are live references to it.
Thanks for your help! I've read the two Effective C++ books by Meyers,
and I've implemented reference-counting classes before -- the
problem was that while Meyers suggests that reference counting should be
transparent for the classes' clients, the ROOT implementation apparently
requires the clients to scan the containers, despite the fact that it
wasn't the client who _filled_ these containers.
(BTW: I checked the site, but didn't find the article. Do you happen
to have the complete URL?)
> At 04:56 AM 9/14/98 -0500, Valery Fine wrote:
> >
> >> Doesn't the destructor remove them from the containers?
> >
> > No it doesn't. Since the object has not "backward pointer to the
> >container ('s !).
> >
> > This means to be "right" ROOT (and any other C++ program too) must
> >scan ALL containers created to find out whether the deleted object
> >did belong one of them.
Shouldn't this be the task of whoever *registers* to the containers?
I mean, these containers are implicit, the client (that would be me)
doesn't even know them. The constructor registers my instances to these
containers I didn't even know were actually in existence, so it would
be up to the destructor to remove them (the instances).
Cheers, patrick
This archive was generated by hypermail 2b29 : Tue Jan 04 2000 - 00:34:37 MET