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