RE: TTree::Fill problem when TBranch name matches data member name

From: Philippe Canal <pcanal_at_fnal.gov>
Date: Wed, 01 Mar 2006 09:41:31 -0600


Hi Nick,

Thanks to Paul Russo, this problem is now fixed in the CVS repository.

Cheers,
Philippe.

-----Original Message-----
From: owner-roottalk_at_pcroot.cern.ch [mailto:owner-roottalk_at_pcroot.cern.ch] On Behalf Of Nick West
Sent: Tuesday, February 21, 2006 12:00 PM To: roottalk_at_pcroot.cern.ch
Subject: [ROOT] TTree::Fill problem when TBranch name matches data member name

Dear RootTalk,

We (MINOS) have been having trouble filling TTrees since we moved to 5.08/00 on Scientific Linux SL Release 3.0.4 with gcc version 3.2.3

I have isolated the problem into a simple ACLiC macro in which there are two classes:-

class ClassA : public TObject {

  Int_t event;
  Int_t num_2;
  Int_t num_3;
  Int_t num_4;

  ...};
class ClassB : public ClassA {
  Int_t num_1;
  Int_t num_2;
  Int_t num_3;
  Int_t num_4;

...};

that are used to fill a TTree and then display the contents:-

  ClassB* class_b = new ClassB();
  TTree* fNtuple = new TTree("NtupleTest", "Ntuple Test");

  fNtuple->Branch("event.", "ClassB", &class_b, 64000, 2);
  fNtuple->Fill();
  fNtuple->Show(0);

Although the object initialise themselves like this:-  

  ClassA() {

    event = 1;
    num_2 = 2;
    num_3 = 3;
    num_4 = 4;

  }

  ClassB() {

    num_1 = 101;
    num_2 = 102;
    num_3 = 103;
    num_4 = 104;

  }

Tree::Show(0) produces:-

======> EVENT:0

 event.          = NULL
 event.ClassA.fUniqueID = 0
 event.ClassA.fBits = 50331648
 event.ClassA.event = 4
 event.ClassA.num_2 = 101
 event.ClassA.num_3 = 102
 event.ClassA.num_4 = 103
 event.num_1     = 101
 event.num_2     = 102
 event.num_3     = 103
 event.num_4     = 104

The ClassA results have been shifted by 12 bytes and are actually returning part of ClassB. I have discovered that the problem is related to the fact that the TBranch name is "event." and ClassA has a member named "event". Changing the name of either is sufficient to fix the problem.

The attached ACLiC macro illustrates the problem. It runs fine under 4.04/02 but fails under 5.08/00 and 5.09/00 (taken from CVS head a few days ago).

Now, while it's perhaps not a good idea to duplicate an name like that I wasn't aware that it was a restriction. Is it now?

Thanks,

Nick West Received on Wed Mar 01 2006 - 16:47:03 MET

This archive was generated by hypermail 2.2.0 : Mon Jan 01 2007 - 16:31:57 MET