Hi Birger,
This problem was fixed shortly after the release of 3.05/05 (thus you can use the head of the CVS repository or the upcoming 3.05/06).
Cheers,
Philippe.
PS. There is a work-around for 3.05/05 for some circunstances. However it requires some code to execute EACH time the chain changes its file BEFORE reading the first entry of the new file, so
it is not trivial and can not be used in conjunction with TTree::Draw.
-----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