Re: Which objects are stored by TFile::Write()?

From: Rene Brun (Rene.Brun@cern.ch)
Date: Sat May 31 1997 - 12:00:06 MEST


Jacek M. Holeczek wrote:
> 
> > > What is meant by 'all objects' in this case?
> Correct me, if I'm wrong. It typically means 'all objects that have a
> name' ( and a title ), that means all objects derived from TNamed.
> I have met this problem, too ( my private opinion follows ).
> All root related objects could be divided into two groups. One group
> containing all NAMED objects and the other one containing ANONYMOUS
> objects ( that is NOT derived from TNamed ). Unfortunately ( and that's my
> private opinion ) quite a lot of important classes, existing in root
> framework, appear ONLY in the ANONYMOUS group. I would like to propose,
> that ALL classes ( o.k. almost all ) exist in two "versions" one without
> and one with name/title ( the problem here is, that only NAMED objects
> can be "found" by root when scanning subdirectories, for example ). Why ?

Ideally, it would be nice to always derive from TNamed instead of TObject.
However, for performance reasons, we want to keep the two modes.
There are many objects that are only transient objects and they may be
created by millions.
In ROOT most high level objects are always named objects. The name
is in general given in the constructor. There are a few exceptions like
TGraph and TText.
        Important remarks when writing objects to a file
        ================================================
 1- TNamed derived objects:
    named->Write();
    writes the named object. A key with the name of the object is created.
    named->Write(newname);
    The named object is written with a key = newname different from its name.

 2- TObject derived objects (non deriving from TNamed)
    object->Write();
      object is written with a keyname equal to the object class name.
    object->Write(keyname);
      object is written with a key=keyname.

 3- Root collections (Tlist, TObjArray, etc)
    list->Write();
      this will create a new key for each object (named or not) in the list
    list->Write(keyname,1);
      this will force all objects in the list to be written as one single key.


> I think I like the idea of building applications from loosely coupled
> "modules", each of them placed in a dll. Then, one starts the standard
> root executable, and loads all "extensions" that one needs ( just by
> gSystem.Load or ".L" ). The problem here is - how should these libraries
> communicate ? The best answer is - through "global" objects. I simply
> mean that the "module" "scans" subdirectories trying to find objects that
> it needs, and leaves the "intermediate results" for other modules in the
> same place. This requires, however, that all objects used to this
> communication are "findable", that is have a NAME. The first time I met
> this problem it was the TNamedObjArray class that did not exist, there
> exists only TObjArray ;-( .

Agree with the principle. Note that gROOT->FindObject(name) can already be
used for this purpose. We could extend the functionality of this function
to behave like a Unix search path mechanism.

> I would also like to propose another extension. It would be nice if root
> files could keep ascii files ( also compressed ), for example with c++
> macros used to analyze/display other objects in the same root file ( or
> maybe with some calibration parameters ).
> Jacek.

Yes, agreed. We are open to proposals here.
We already have a class called TSystemFile. One could imagine something like:
  TSystemFile *sfile;  (TNamed object)
  sfile->Write();
   this statement will read the contents of the (Ascii) file and save it
   in the current Root file.
  Now a question. Assume an ascii file named "asciifile.dat" saved in
  a Root file x.root. The key name being "asciifile.dat".
  What should happen when:
   - Interactively the command Root > asciifile.dat  is typed ? or
   - TSystemFile *sfile = (TSystemFile*)gDirectory->Get("asciifile.dat")
   the file may already exist on the local system !
   Should we invoke the editor to view the file ?

What about non-ascii files (example a GIF file) ?

Rene Brun



This archive was generated by hypermail 2b29 : Tue Jan 04 2000 - 00:26:19 MET