Re: find object help

From: Jacek M. Holeczek (holeczek@clri6f.gsi.de)
Date: Tue Feb 18 1997 - 18:28:57 MET


Hi,
> ( ... )
> or, much faster (all inline):
> if (obj->IsA() == TH1S::Class()) {
Nice trick. Thanks.
> ( ... )
> >         4. maybe I should simply forget these "if (..)" and simply Fill(...)
> >            histograms/ntuples, and if they don't exist, they will not be
> >            created/filled ( hopefully this will behave quietly ).
> 
> You'll need some object to fill.
Right. I was thinking like a paw-man here.
In paw I could have "call hf1(9999,1.,1.)" and if 9999 was not available
( booked ) it was not filled ( and not created, of course ). Point.
I would like to get the same behaviour in root. The general idea here is
different, however. Now I need to deliver a pointer to my histogram
h9999->Fill(). Thus I have to find the histogram first. Thus I need to
replace a fortran-paw line :
	if ( hexist(9999) ) call hf1(9999,1.,1.)
with a c-root line :
	if ( h9999 = find_somehow_histogram("h9999") ) h9999->Fill(...)
where I assume that the routine find_somehow_histogram(...) returns null
if it's not available and a correct pointer if it is found.
Now, Fons'es advice was :
> Use pointers to the objects instead of trying to find them by name
> everytime.
> That is, look for them once (assuming they come from file) using either
           ^^^^^^^^^^^^^^^^^^
I can't. Each of my histograms may disappear/reappear between any two
adjacent calls to the function which fills them ( if they exist ).
Sounds strange ? Assume we have the multithreaded root. Now assume one
thread gets events from acquisition, unpacks them using my "function"
( shared library, of course ) which fills histograms - IF THEY EXIST. The
"main" thread is used to look into these histograms on the fly. I would
like to be able to interactively delete histograms ( which I don't want to
watch any more ), create new histograms, ..., without breaking the thread
that gets/unpacks events. The whole "inteligence" should be placed in the
fool-proof unpacking function. I don't like the idea to additionaly have
( and maintain ) a set of global-histogram-pointers SHARED between
compiled library and interpreted code ( apart from the histogram-objects
themselves ).
> gFile->Get("EventLength") (searches whole file) or
> gDirectory->Get("EventLenght")
> (searches only the directory).
Once again, the routine should be as fool-proof as possible. It should
scan ONLY the MEMORY. If the user has opened a file, the gDirectory points
to that file, but the routine should still scan RAM. In best case, if
possible, the LAST subdirectory  which was used in MEMORY ( before the
file was opened ). In case this RAM-subdirectory cannot be recovered, I
could assume that only the gROOT should be allowed. So the first line of
code would be "lastRAMsubdirectory->cd()" ( or "gROOT->cd()" ).
The TDirectory::Get(...) seems still too complex for me ( to get the
required speed ). I was thinking yesterday about extracting the first part
from it ( called "Case of Object in memory" in source code ), but maybe
there is someting simpler/faster existing ( I'm not sure, but I think I
don't need the source code part "Case of Key" of this routine ).
Thanks in advance,
Jacek.



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