Re: Bug in TObjArray?

From: James Jackson <james.jackson_at_cern.ch>
Date: Fri, 17 Sep 2010 09:09:51 -0500


Sure, I just mentioned it as 'an interest' without the detail. I learned the hard way a good few years back when getting very strange behaviour as I had made assumptions about how the subscripting operator was working. I'm very suspicious of them now ;-)

Regards,
James.

On 17 Sep 2010, at 08:41, John Idarraga wrote:

> Well, not quite.  In the case of a std::map when you use the subscripting operator you are effectively pushing a (key,value) to the map (if the key didn't exist).  That is not really what happens here.  In the case of a std::vector when you use the subscripting operator on a wrong index, you get a segfault.  vector::at is more alike, and it actually throws exceptions.  TObjArray seems to have a different behaviour in that sense.  But that seems alright to me ... one can imagine cases where safe upper-bounds are all you need for the number of Entries, and you don't want to spend time getting the exact number.
> 
> But, if that is the case, now that we are discussing this,  may be GetEntriesFast() should be changed to GetEntries() in the code automatically generated by
> 
> TTree::MakeClass()
> 
> the reason is that if the user changes the constructor (which is by default bound to a given file) and feeds it with a TChain (usually with the goal of loading more than one file), GetEntriesFast() don't return the right number of entries.
> 
> cheers,
> 
> John
> 
> James Jackson wrote:
>> It's worth noting that some STL containers have similar behaviour, for similar reasons. For example std::map.
>> 
>> Regards,
>> James.
>> 
>> On 17 Sep 2010, at 08:06, Fons Rademakers wrote:
>> 
>>  

>>> The problem with TObject *&operator[] is that it can be used as an lvalue:
>>>
>>> a[0] = new TObject
>>>
>>> and hence when using it we assume it will be set and GetEntriesFast() will return it as set. In your case if you loop over the array then GetEntriesFast() will serve as a safe upper-bound. If you use At(), as Axel suggests to access values there is no problem.
>>>
>>> Cheers, Fons.
>>>
>>>
>>>
>>> On 17/09/2010 14:50, Axel Naumann wrote:
>>>
>>>> Hi John,
>>>> 
>>>> as I said, operator[] is intentionally not const: it's used to adds
>>>> elements via placement new(). I think you're looking for the member
>>>> function At().
>>>> 
>>>> Cheers, Axel
>>>> 
>>>> John Idarraga wrote on 09/17/2010 02:44 PM:
>>>>      
>>>>> But then why Arr.GetEntries() gives 0 ?  I thought the Fast version of
>>>>> GetEntries was precisely a Fast access to the number of entries, only
>>>>> safe when you have not performed any manipulation.  Available for
>>>>> certain cases.  I agree with Vassili that it is somewhat annoying and
>>>>> may be an error prone.  But I may be misunderstanding.
>>>>> 
>>>>> thanks,
>>>>> 
>>>>> John
>>>>> 
>>>>> Axel Naumann wrote:
>>>>>        
>>>>>> Hi Vassili,
>>>>>> 
>>>>>> yes, that's on purpose, think of
>>>>>> 
>>>>>>  new (Arr[0]) TObject;
>>>>>> 
>>>>>> Cheers, Axel.
>>>>>> 
>>>>>> 
>>>>>> Vassili Maroussov wrote on 09/17/2010 02:31 PM:
>>>>>> 
>>>>>>          
>>>>>>> Dear ROOTers,
>>>>>>> 
>>>>>>> I'm wondering why TObjArray is designed in such a way that an attempt to
>>>>>>> access the [fLowerBound] element of an empty TObjArray doesn't cause any
>>>>>>> error (please see the example attached). Moreover, it has a rather
>>>>>>> unpleasant side effect: after the access GetEntriesFast() reports that
>>>>>>> the array isn't empty any more. Is it done purposely?
>>>>>>> 
>>>>>>> Regards,
>>>>>>> 
>>>>>>> Vassili
>>>>>>> 
>>>>>>> 
>>>>>>>            
>>>>>>          
>>>>>        

>>> --
>>> Org: CERN, European Laboratory for Particle Physics.
>>> Mail: 1211 Geneve 23, Switzerland
>>> E-Mail: Fons.Rademakers_at_cern.ch Phone: +41 22 7679248
>>> WWW: http://fons.rademakers.org Fax: +41 22 7669640
>>>
>>>
>> 
>>  
> 
Received on Fri Sep 17 2010 - 16:09:57 CEST

This archive was generated by hypermail 2.2.0 : Fri Sep 17 2010 - 17:50:01 CEST