RE: Problems using STL vectors in trees with TTree::Draw()

From: Philippe Canal <pcanal_at_fnal.gov>
Date: Fri, 23 Feb 2007 08:58:25 -0600

> tree->Print() throws errors of Error in <TStreamerInfo::BuildOld>:
> Could not find STL base class: vector<Thing> for Vector<Thing>

Try also generating the dictionary for vector<Thing>.

> If I have two vectors with overlapping leaf names, then
> there is no way to specify which tree I want to draw. That is,
> tree->Draw("branch.mElement") doesn't work.

When creating the branch add a trailing dot (.):

   tree->Branch("branch.","Vector<Thing>",&a);

> What does work is tree->Draw("vector<Thing>.mElement")
> but it gives inconsistent results! Subsequent draw commands, like
> tree->Draw("vector<Thing>.mElement - 10") will give different plots!

Strange ... Could you provie a running example reproducing this?

> This is useless if you have two Vector objects with similarly-named
> mElement leaves.

This is the same issue as 'branch.mElement' above. Simply create your branch with a trailing dot.

> I attempted to get around this by writing a custom streamer for my
> object.

I don't why it would help :)

Also note that writing a custom streamer disable the splitting. However it disable it at write time.
If you write your object without a streamer, then they will be split on file (if requested) and when you read them back (since they are already split on file), the streamer will not be used.

> However, the custom streamer was never called when I did
> TTree::Fill().

This is odd. Maybe your streamer was not properly seen (maybe your dictionary was out of date), could you provide an example reproduce this behavior?

Cheers,
Philippe

-----Original Message-----
From: owner-roottalk_at_pcroot.cern.ch [mailto:owner-roottalk_at_pcroot.cern.ch] On Behalf Of Nathaniel Tagg
Sent: Friday, February 23, 2007 7:33 AM
To: roottalk_at_pcroot.cern.ch
Subject: [ROOT] Problems using STL vectors in trees with TTree::Draw()

Hi ROOTers,

I'm trying to use STL vectors in trees. Vectors are by FAR easier to work with than TClonesArrays, so I want to use them in our code. However, the resulting TTrees do not work with TTree::Draw commands. I'm using ROOT 5.13 and 5.14 for my tests.

Problem (1)

---

If I branch a tree like the following:

template<class T>
class Vector : public std::vector<T>, public TObject {
  ....
}

Vector<Thing>* a;
tree->Branch("branch","Vector<Thing>",&a);

I make sure that Thing and Vector<Thing> are correctly built with rootcint. The resulting root tree, however, is pretty ugly:

tree->Print() throws errors of Error in <TStreamerInfo::BuildOld>: Could not find STL base class: vector<Thing> for Vector<Thing>

tree->Draw commands are not simple. If I have two vectors with overlapping leaf names, then there is no way to specify which tree I want to draw. That is,
tree->Draw("branch.mElement") doesn't work.

What does work is
tree->Draw("vector<Thing>.mElement")
but it gives inconsistent results! Subsequent draw commands, like tree->Draw("vector<Thing>.mElement - 10") will give different plots!

Problem (2)

---

I read somewhere on roottalk that top-level vectors aren't very good, so I tried this instead:

template <class T>
class Vector : public TObject
{
...
private:

        std::vector<T> mV
};

However, this gives a similar problem... you cannot address specific branches on the tree.

tree->Draw("branch.mV.mElement");
Error in <TTreeFormula::Compile>: Bad numerical expression : "branch.mV.mElement"
tree->Draw("branch.mV[0].mElement");
Error in <TTreeFormula::Compile>: Bad numerical expression : "branch.mV[0].mElement"

This is useless if you have two Vector objects with similarly-named mElement leaves.

Problem(3)

---

I attempted to get around this by writing a custom streamer for my object. However, the custom streamer was never called when I did TTree::Fill(). Instead, ROOT defaulted to it's standard STL steamers. This is an undocumented behaviour.

In all of these problems, I THINK it's because I have my splitlevel turned up quite high. I would like to keep this since it allows much faster data retrieval.

Any advice what I should try?

--Nathaniel Tagg Received on Fri Feb 23 2007 - 16:00:28 CET