Hi Birger, A simple equivalent test does not show this problem. Could you send us more information. For example: root [] file = new TFIle("ecs63138"); root [] file->GetStreamerInfoList()->ls(); > infolist.txt root [] T13->Print(); > treeprint.txt Cheers, Philippe. -----Original Message----- From: koblitz@poly.in2p3.fr [mailto:koblitz@poly.in2p3.fr] Sent: Wednesday, July 16, 2003 7:04 AM To: Philippe Canal Cc: Rene Brun; roottalk@pcroot.cern.ch Subject: RE: [ROOT] Why are constructores called when branches are not read? Hi, actually it seems that disabling reading branches does not work as expected: > cd /afs/cern.ch/user/k/koblitz/scratch0/h4 > root ******************************************* * * * W E L C O M E to R O O T * * * * Version 3.05/05 8 May 2003 * * * * You are welcome to visit our Web site * * http://root.cern.ch * * * ******************************************* FreeType Engine v2.1.3 used to render TrueType fonts. Compiled for linux with thread support. CINT/ROOT C/C++ Interpreter version 5.15.86, Apr 29 2003 Type ? for help. Commands must be C++ statements. Enclose multiple statements between { }. root [0] gSystem.Load("/afs/cern.ch/user/k/koblitz/public/h4/rawroot/Linux/libRawEvent.so"); root [1] TChain *inputChain = new TChain("T13","H4 Analyis Input Chain"); root [2] inputChain->Add("ecs63138"); root [3] inputChain->SetBranchStatus("*",0); root [4] inputChain->GetEntry(1); end TRawTdcInfo::Init() end TRawTdcInfo::Init() end TRawTdcInfo::Init() TRawTower constructor TRawTower constructor Clearly the TRawTower constructor is being called although the branch is supposed to not be read (inputChain->SetBranchStatus("*",0);) The class TRawTdcInfo does not reference the towers. Is this maybe a problem in TChain??? Cheers, Birger On Tue, 15 Jul 2003, Philippe Canal wrote: > Hi, > > What you see is the expected behavior. > > The semantic of TTree::GetEntry and TChain::GetEntry is to read ALL the > branches by default. In order to read only some of the branches, you need > to explicitly call tree/chain->SetBranchStatus to disable the branch you are > not interested. Reading all the branches is the default behavior since it > is the most common use. > > When reading a branch for which the address has not been set (i.e > tree/chain->SetBranchAddress has not been called) or the pointer passed to > SetBranchAddress is null, the tree allocates memory for the object. This is > done by calling the default constructor. In subsequent GetEntry, the > allocated object will be re-used by calling the Streamer for each entry. > > In the case of a chain and a branch for which SetBranchAddress has not been > called, the object will be deleted and re-allocated at each file boundary. > > > In my opinion this should not happen since calling default constructors > may not > > work in a certain context and may be time-consuming. > > In those circunstances, the user is responsible for either calling > SetBranchAddress and allocating the object or disabling the branch. > > Cheers, > Philippe > > -----Original Message----- > From: owner-roottalk@pcroot.cern.ch > [mailto:owner-roottalk@pcroot.cern.ch]On Behalf Of koblitz@poly.in2p3.fr > Sent: Tuesday, July 15, 2003 11:55 AM > To: Rene Brun > Cc: roottalk@pcroot.cern.ch > Subject: [ROOT] Why are constructores called when branches are not read? > > > Hi Rene, > > I am trying to find a bug which may be in the way TChain works. My problem > is that GetEntry(1) seems not to fill the objects which are read correctly > if 2 files are on the chain while it works for both files individually. It > already crashes reading the first event on the first file. During my > investigation I started to wonder why constructors of Objects are called > by GetEntry, even if we did not attach to any branch on the tree. In my > opinion this should not happen since calling default constructors may not > work in a certain context and may be time-consuming. So if I dont read a > branch the constructors of the object on the branch should never be > called. If you want to reproduce this, try the following: (libRawEvent is > J. Bourottes H4 ECAL code and the ecs file was produced by him). > > > On lxplus do: > > cd /afs/cern.ch/user/k/koblitz/scratch0/h4 > > root > ******************************************* > * * > * W E L C O M E to R O O T * > * * > * Version 3.05/05 8 May 2003 * > * * > * You are welcome to visit our Web site * > * http://root.cern.ch * > * * > ******************************************* > > FreeType Engine v2.1.3 used to render TrueType fonts. > Compiled for linux with thread support. > > CINT/ROOT C/C++ Interpreter version 5.15.86, Apr 29 2003 > Type ? for help. Commands must be C++ statements. > Enclose multiple statements between { }. > root [0] > gSystem.Load("/afs/cern.ch/user/k/koblitz/public/h4/rawroot/Linux/libRawEven > t.so"); > root [1] TChain *inputChain = new TChain("T13","H4 Analyis Input Chain"); > root [2] inputChain->Add("ecs63138"); > root [3] inputChain->GetEntry(1); > end TRawTdcInfo::Init() > end TRawTdcInfo::Init() > end TRawTdcInfo::Init() > TRawTower constructor > TRawTower constructor > root [4] > > A trace gives: > Breakpoint 2, TRawTdcInfo::Init (this=0x89fb140) at TRawTdcInfo.cxx:48 > 48 fNValue = 0; > (gdb) bt > #0 TRawTdcInfo::Init (this=0x89fb140) at TRawTdcInfo.cxx:48 > #1 0x401297e2 in TRawTdcInfo::TRawTdcInfo (this=0x89fb140) at > TRawTdcInfo.cxx:20 > #2 0x401387b7 in ROOT::new_TRawTdcInfo (p=0x0) > at /coda/software/root/v3.05.05/include/TObject.h:154 > #3 0x4031af79 in TClass::New () from > /coda/software/root/v3.05.05//lib/libCore.so > #4 0x40ec3de0 in TBranchElement::SetAddress () > from /coda/software/root/v3.05.05//lib/libTree.so > #5 0x40ec2843 in TBranchElement::GetEntry () > from /coda/software/root/v3.05.05//lib/libTree.so > #6 0x40edbc90 in TTree::GetEntry () from > /coda/software/root/v3.05.05//lib/libTree.so > #7 0x40ec7add in TChain::GetEntry () > from /coda/software/root/v3.05.05//lib/libTree.so > #8 0x4006c9a5 in H4Analysis::nextEvent (this=0x86b8f28) at > H4Analysis.cxx:384 (---------> chain->GetEntry(1) ) > #9 0x08049415 in main (argc=1, argv=0xbffff654) at pulse.cc:29 > #10 0x42017499 in __libc_start_main () from /lib/i686/libc.so.6 > > Maybe if I understand this puzzel, I finally understand why a chain works > with 1 file but not with 2. > > Cheers, > Birger > > > -- > Birger Koblitz Tel: +33/1 69 33 31 73 > Ecole Polytechnique - LLR > Route de Saclay > F-91128 Palaiseau > -- Birger Koblitz Tel: +33/1 69 33 31 73 Ecole Polytechnique - LLR Route de Saclay F-91128 Palaiseau
This archive was generated by hypermail 2b29 : Thu Jan 01 2004 - 17:50:13 MET