Patrick Schemitz wrote:
>
> 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
We all know about this theory.
I have to correct a misleading information in a previous message
by Valery Fine.
The TMaterial destructor removes the reference to the material
object in the container of materials.
For none of the existing Root classes, the user has to scan
the list of containers. This is automatic in the object destructors.
Many Root objects are automatically added to a container by
their constructors.
The TROOT class documentation header says:
// The TROOT object is the entry point to the ROOT system.
// The single instance of TROOT is accessible via the global gROOT.
// Using the gROOT pointer one has access to basically every object
// created in a ROOT based program. The TROOT object is essentially a
// container of several lists pointing to the main ROOT objects.
//
// The following lists are accessible from gROOT object:
// gROOT->GetListOfClasses
// gROOT->GetListOfColors
// gROOT->GetListOfTypes
// gROOT->GetListOfGlobals
// gROOT->GetListOfGlobalFunctions
// gROOT->GetListOfFiles
// gROOT->GetListOfMappedFiles
// gROOT->GetListOfSockets
// gROOT->GetListOfCanvases
// gROOT->GetListOfStyles
// gROOT->GetListOfFunctions
// gROOT->GetListOfSpecials (for example graphical cuts)
// gROOT->GetListOfGeometries
// gROOT->GetListOfBrowsers
Rene Brun
This archive was generated by hypermail 2b29 : Tue Jan 04 2000 - 00:34:37 MET