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.
