Re: Couple of questions/comments regarding TRefs in a array (5.18.00a)

From: Constantin Loizides <loizides_at_MIT.EDU>
Date: Mon, 14 Jul 2008 12:21:33 +0200

Hi Rene,
thanks for the fast response.

Would option a) the TRefArray also work if I'd start to mix events where the contents of the event come from two different files/processes?

Not clear to me how to "associate" the TRef to the TRefArray, what do you mean by that?

(Would I still call TTree::BranchRef())

Thanks,
Constantin

Rene Brun wrote:

> Hi Constantin,
> 
> Constantin Loizides wrote:

>> Dear all,
>>
>> I'd like to store an array of TRefs in a class that
>> itself is stored in a TClonesArray. The TRefs can point
>> to objects in different branches of the same tree.
>> The following are my findings/questions for 5.18.00a.
>>
>> a) Using a TRefArray:
>> TRefs stored in TRefArray seem not to support
>> autoloading via TTree::BranchRef()?

> correct. We will implement this possibility in a medium term version. 
> For the time being you must associate a TRef object to the TRefArray to 
> force the autoloading of another branch.

>>
>> Also not sure if TRefArray would be split?

> This does not make sense. The TRefArray elements are streamed to the 
> same buffer.

>>
>> Assuming the above two points could be
>> made to work. What happens if I merge two trees created
>> in different processes? From the description of the
>> TRefArray I would rather guess that this is not
>> supported?

> You can perfectly merge two trees containing TRef and TRefArray. The 
> corresponding TProcessID objects from all the files are copied to the 
> result file.

>>
>> b) Using a TClonesArray of TRef
>> Autoloading worked but the TClonesArray was not split.
>> Is this a restriction when having a TClonesArray inside
>> a TClonesArray?

> This a violation of the good old principles of a TClonesArray, ie having 
> variable length collections
> in a variable length collection.

>>
>> c) Using a std::vector of TRef
>> Autoloading and splitting works, so this is what I am
>> using for now.

> Yes, this should be OK, although far much less efficient (memory, time 
> and file space wise)
> than a TRefArray.

>> My experience with ROOT and std::vector
>> is limited however. In particular I'd like to know if
>> I have to "trim" the std::vector to its minimal size
>> before storing it? In other words assuming its capacity
>> is bigger than its size, on read time would I recreate
>> the std::vector as it was before with the larger
>> capacity or would ROOT create the std::vector just with
>> the needed size?

> std::vector are automatically trimmed to the exact size and rebuilt at 
> the correct length
> when reading. This is done automatically.
> 
> Rene Brun

>>
>> Thanks,
>> Constantin
>>

>

-- 
Phone: +41-22-76 78948 (CERN)
Skype: loizides / AOL: ConLoi

Received on Mon Jul 14 2008 - 12:21:45 CEST