List:MySQL++« Previous MessageNext Message »
From:Rick Gutleber Date:October 13 2008 2:01pm
Subject:Re: [documentation] Confusion: vector::operator[] and exceptions
View as plain text  
Warren Young wrote:
> me22 wrote:
>> vector::operator[] does not throw exceptions
>> for out-of-range indexes, so I was surprised that Row does.
>
> I consider that a design error in STL.  Unchecked array indexing is 
> sooo last millennium.  I stick by Row::operator[]() being implemented 
> in terms of vector::at() under the hood.
What?!  Just because it caused billions of dollars and man-hours worth 
of damage in Microsoft Windows over the last decade you think we should 
be checking array bounds?  Wotta fascist!  ;-)
>
>> it seems that operator[] is actually calling the vector's at.
>> That seems like a waste of time, since it's already checked that the
>> index is valid.
>
> That's true for char* indexes, but not for int.  I can see changing 
> the char* case to use vector::operator[] instead.  I can't study it 
> right now, but consider it on the wishlist for 3.0.7.
>
>> And in the case that the index *is* out of range, it
>> throws a custom exception, not the one from vector::at, contrary to
>> the documentation.
>
> Hmmm, yes, I'll have to think about this, too.  I'm not sure if the 
> exceptions need to be harmonized, or the docs need to be clarified.
>
I'd be inclined to suggest throwing standard exceptions everywhere they 
could possibly be applicable.

With respect to STL, I'm not familiar with the details of what throws 
and what doesn't, and I strongly support your stance on array bounds 
checking, I'm not entirely sure that's a design error.  Allowing some 
flexibility in the matter is good too.  In the past I implemented a set 
of collection classes, similar to STL but not based on templates (this 
started in the days when templates weren't standardized and STL was 
still in its infancy, and yes, that means there was some serious macro 
juju being done) and I implemented the checks at the higher levels and 
kept lower-level functionality (private internal methods) check-free to 
avoid checking when it wasn't necessary (i.e., you already knew the 
index was safe, etc).  While std::vector _is_ an end-user class and 
therefore exposes "unsafe" operators, perhaps this is the thinking 
behind it _not_ doing bounds checking.  I'm just shooting in the dark 
here. 

Even today, performance is still an issue.  Checking is imperative but 
if an array index is checked several times between the call at the 
"user" level and the lowest-level operation that actually does the work, 
that's a serious problem too.

Thread
[documentation] Confusion: vector::operator[] and exceptionsme2211 Oct
  • Re: [documentation] Confusion: vector::operator[] and exceptionsWarren Young11 Oct
    • Re: [documentation] Confusion: vector::operator[] and exceptionsRick Gutleber13 Oct
  • Re: [documentation] Confusion: vector::operator[] and exceptionsWarren Young8 Nov