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
>
>
Received on Tue Jan 18 2011 - 09:24:29 CET