Hello Rene,
thank you for the quick answer.
On Fri, 15 Jan 1999, Rene Brun wrote:
[...]
> A data base will typically be a combination of these 2 modes.
> A reconstruction program will typically use more the first form.
> A final analysis program will use almost exclusively
> the last form (like ntuples).
I know that many of our collegues do that on ntuples (not with ROOT).
Maybe powerful "non-rectangular structure" would be more convenient and
efficient. I do not believe that all information has to be condensed to
scalar arrays before they are filled into histograms. Instead, the use of
member functions and polymorphism could be a gread advantage, even in
final analyses.
> > * The polymorphic version stores objects, which are referenced by others,
> > and recreates them when the others are read from the tree. A hashing
> > mechanism makes sure, that they are only loaded once per branch. The
> > problem is, that they are not deleted, when the next event is loaded. This
> > should be simple, since a list of all specially created objects must
> > exist. Up to now, I make my own hash table, looking up the TDataMembers.
> > That really takes some time. This small extension to ROOT would help a
> > lot.
>
> I do not understand this point. Root will automatically delete
> any previous object attached to a pointer. You do not need
> to delete the objects of the previous event before reading
> the second event.
I am not sure, whether I expressed that correctly. Here is an example:
class A: public TObject
{
public:
A();
~A();
A* f;
ClassDef(A,1)
};
I attach such an object to a branch and do something like a->f=new A (and
maybe a->f->f=new A) and write it to a file. When I read these chains of
objects back, everything is correctly restored, but a cout statement in
the constructors and destructors shows me, that not all objects are
deleted:
----------------------------------------------------------------------
root [18] x.GetEvent(1)
deleting 0x47f178
creating 0x47f178
creating 0x53e738
(Int_t)34
root [19] x.GetEvent(0)
deleting 0x47f178
creating 0x47f178
creating 0x53e760
(Int_t)34
----------------------------------------------------------------------
Have I overlooked something or do I have to be more precise? Is there a
way to look up these objects? The gObjectTable does not seem to contain
them.
[...]
> A TClonesArray IS self-describing. As a proof, you can generate
> automatically the analysis code via TTree::MakeClass.
> There is also no problems with classes having the same attribute
> name in different TClonesArray. A TClonesArray goes to one
> super-branch. Each attribute of the referenced class in turn
> goes to a separate branch.
> During the analysis, an attribute of a class in a TClonesArray
> can be referenced by
> - its attribute name if it is unique.
> - branchName.Attributename if it is not unique.
[...]
I have received the recommendation to replace pointers in TClonesArrays by
integers, which "point to" a certain element of another TClonesArray. This
has advantages in memory consumption and can be efficiently compressed. My
point was, that such an integer is not self-describing. It is up to the
user to choose a name, which is enough of a hint, in which ClonesArray to
look up the referenced object. And to which type to cast it. As far as I
understand, there is no way to get the correct types of objects from a
TClonesArray. It would only be possible with templates.
This might be an interesting CINT extension. It could look up the type of
TObjects via Class(). This would help in such situations:
histogram = file.Get("histogram");
If you don't put in a (TH1F*) cast, you get a TObject* histogram, which is
not very useful. And it's hard to get rid of it.
Kind regards
Christoph
--
Christoph Borgmeier Mail: DESY F15/HERA-B, Geb. 61/117
Notkestr. 85, 22607 Hamburg
Humboldt Univ Berlin Phone: +49 40 8998 4850
Email: Christoph.Borgmeier@desy.de
This archive was generated by hypermail 2b29 : Tue Jan 04 2000 - 00:43:28 MET