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

Hello everyone,

I am finally confused with Erkcan's question and now reading the whole thread I would like to ask myself again this way. In one direction, if I have a pointer to std::vector in my data (root file) and I read (with MakeClass) with a member which is a c-style array, there should be no problem at all on pointing to the beginning of the array stored in the vector. Is this right, if not, can you tell me why ? I don't see any harm in doing this, under the condition that the vector remains unchanged.

The other way around the problem is clear. If I am reading a pointer to std::vector and I want to read it with the same structure I need to make sure I am passing the same pointer to a vector, otherwise there will be memory alignment problems. In fact, it shouldn't even compile.

thanks ... interesting discussion,

J.

Axel Naumann wrote:
> Hi,
>
> Internally, ROOT assumed that you did indeed pass a std::vector,
> reinterpreted the memory you passed as a std::vector, called resize() on
> it and then filled the elements. So for all implementations that I am
> aware of, all but the first few (or one) c-style elements *can*
> (depending on the type of the elements) look reasonable.
>
> Anyway: you now know how to do it right :-)
>
> Cheers, Axel.
>
> Erkcan Ozcan wrote on 01/19/2011 08:16 AM:
>
>> Hi Philippe,
>>
>> Thanks for the response. Just to bring this thread to a full conclusion: In my original email that started the thread, I had written that we had found that it did seem to work. Now when you say it doesn't, do you mean, it would crash right away, or it would just work by luck, but would be unreliable?
>>
>> Cheers,
>> e.
>>
>> On 18 Jan 2011, at 20:09, Philippe Canal wrote:
>>
>>
>>> Hi,
>>>
>>>
>>>> Given a branch which is found to be a *vector<POD> by MakeClass(), can I instead call SetBranchAddress with a c-style array?
>>>>
>>> No this unfortunately does not work. The address passed must be for an actual std::vector object.
>>>
>>> Philippe.
>>>
>
>
Received on Fri Jan 21 2011 - 13:52:10 CET