Re: c-style arrays used in setbranch for std::vector branches

From: Erkcan Ozcan <eo_at_hep.ucl.ac.uk>
Date: Tue, 18 Jan 2011 13:06:20 +0200

Hi Axel,

That is good to know. Actually my question was the reverse. Given a branch which is found to be a *vector<POD> by MakeClass(), can I instead call SetBranchAddress with a c-style array?

Thanks a lot,
e.

On 18 Jan 2011, at 10:24, Axel Naumann wrote:

> Hi,
> 
> to clarify my reply:
> 
> Given a branch containing a c-style array (POD* where POD is float,
> double,...), you can call SetBranchAddress() passing a vector<POD>'s
> first element's address (&v[0]), as long as the vector has sufficient
> capacity and doesn't resize. I believe that's what the question really
> was in the end.
> 
> Cheers, Axel.
> 
> Axel Naumann wrote on 01/17/2011 09:14 PM:
>> Hi, 
>> 
>> That should work as long as the vector doesn't resize, as you already pointed out. And make sure you reserve enough capacity before calling SetBranchAddress(). 
>> 
>> Cheers, Axel 
>> 
>> "Erkcan Ozcan" <eo_at_hep.ucl.ac.uk> wrote:
>> 

>>> Hi John,
>>>
>>> Thanks. When I said cast, I indeed phrased wrongly: I had meant &v[0]
>>> as you suggested. However, I think it is still not the best thing to
>>> do: C++98 standard does not guarantee that the memory allocated by
>>> std::vector will be contiguous, that requirement was added in TR1.
>>> Luckily, I think all compilers do it contiguously these days, that is
>>> why people can use &v[0].
>>>
>>> But please note that if the size of the std::vector changes,
>>> std::vector might carry the elements elsewhere in memory and the memory
>>> address for v.begin() might change. Furthermore, my question might not
>>> be simply a std::vector to c-array dereferencing question, it is
>>> related to how the ROOT authors implemented std::vectors in TTree and
>>> whether TTree->SetBranchAddress() works safely when I give a pointer to
>>> a c-array instead of a pointer to an std::vector to it.
>>>
>>> Thanks for the input though.
>>>
>>> Cheers,
>>> e.
>>>
>>> On 17 Jan 2011, at 01:42, John Idarraga wrote:
>>>

>>>> Hello Erkcan,
>>>> 
>>>> This is fine because there is not really a cast taking place.  If you

>>> create a std::vector of floats for instance:

>>>> 
>>>> vector<float> v;
>>>> 
>>>> you can always safely reference the array of floats inside by doing

>>> &v[0] (say for example in the constructor of a TGraph ... that kind of
>>> situations).

>>>> 
>>>> So it is safe as long as you deal correctly with the size of the

>>> array. You probably have a variable for that. In case you don't there
>>> is always the clever trick of sizeof(array)/sizeof(float) ;)

>>>> 
>>>> cheers !
>>>> 
>>>> John Idarraga
>>>> 
>>>> On 01/16/2011 05:59 PM, Erkcan Ozcan wrote:
>>>>> Dear ROOT experts,
>>>>> 
>>>>> We have an ntuple that contains std::vectors of floats and ints.

>>> When we do MakeClass() we get branches like this:

>>>>> 
>>>>> vector<float>    *pvx;
>>>>> 
>>>>> We also have an old piece of code written before the ntuple format

>>> was modified and it used to use c-style arrays. The same branch used to
>>> be:

>>>>> 
>>>>> float  pvx[10];
>>>>> 
>>>>> And we were doing the following setbranch step:
>>>>> 
>>>>> anltree->SetBranchAddress("pvx"     ,&pvx);
>>>>> 
>>>>> We have found out that the code seems to work on the new ntuples

>>> without any modifications, ie. we still define c-style arrays and
>>> setbranch to a branch which is really a pointer to an std::vector.

>>>>> 
>>>>> Is this safe to do? I know normally it is not ok to cast an

>>> std::vector to a c-style array, but given that in this scenario we will
>>> only be reading from a ROOT file, perhaps what we do is completely
>>> fine. Could some expert confirm please?

>>>>> 
>>>>> Thanks a lot,
>>>>> e.
>>>>> 
>>>>> PS: I have had some problems when I sent this email the first time.

>>> Apologies to all the mailing list members if we end up getting it
>>> twice.

>>>>> PS2: We are using ROOT 5.26/00b.
>>>>> 
>>>>> 
>>>> 

>>>
>>> --
>>>
>>> In case they are not written explicitly, please be aware that my
>>> greetings and farewell are inherently implied in this email.
>>>
>>> V. Erkcan Ozcan
>>> Research Fellow
>>> University College London
>>> Dept. of Physics & Astronomy
>>>
>>>
>>> --
>>>
>>> In case they are not written explicitly, please be aware that my
>>> greetings and farewell are inherently implied in this email.
>>>
>>> V. Erkcan Ozcan
>>> Research Fellow
>>> University College London
>>> Dept. of Physics & Astronomy

>> 
>> 
> 

-- 

In case they are not written explicitly, please be aware that my greetings and farewell are inherently implied in this email.

V. Erkcan Ozcan
Research Fellow
University College London
Dept. of Physics & Astronomy

Received on Tue Jan 18 2011 - 12:06:43 CET