Re: bounds checking in array.hpp

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-12-15 18:33:26

--- In boost_at_[hidden], Jesse Jones <jejones_at_a...> wrote:
> >From: Jesse Jones [mailto:jejones_at_a...]
> >> >I notice that bounds checking in array.hpp is only done when 
the at()
> >> >methods are used. I think it would be a great boon to the 
community
> >> >using boost if there could be a debug mode -- either use 
asserts or,
> >> >as the STLPort does, have a boost_debug namespace and do range
> >> >checking for classes imported from there. Does this make sense?
> >>
> >> Most definitely.
> >
> >This is standard for all STL containers. The at() form does bounds 
checking,
> >and the operator[] form is fast and does not. While I don't object 
in
> >principle to a "debug mode" flag which makes operator[] the same 
as at(), I
> >am happy with things as they stand. I would object if 
the "release" mode
> >differed from the established practice in the standard library.
> 
> The standard says that at() must throw if the precondition is 
violated and
> that the behavior of operator[] is undefined. It's true that most 
vendors
> do a poor job of catching precondition violations, but there's no 
reason
> for boost to go along with this. I strongly support liberal usage of
> assertions in boost.

It's not true that most vendors do a poor job of catching 
precondition violations.  operator[] should not, in general, do any 
checks because such checks require overhead that would render 
std::vector a poor replacement for built-in arrays for many uses.  
For this reason, most implementations do not do any precondition 
checks on operator[], and rightfully so regardless of whether or not 
the standard allows them to.  If you want checking, use at().

It may be valid to have debugging support for bounds checking in 
operator[], though this can result in an unrealistic belief that your 
code is safe when compiled in release mode.  For this reason, I'm not 
sure I'm in favor of implementations that check in debug builds and 
use operator[] only when speed is important and/or I can insure 
there's no range errors at compile time.

Bill Kempf