Re: bounds checking in array.hpp

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-12-18 09:58:45

--- In boost_at_[hidden], Jesse Jones <jejones_at_a...> wrote:
> >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.
> 
> A quality library should define good preconditions and 
postconditions.

You cut out part of the quote.  Paul Moore said:

> >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.

Your reply seemed to indicate that library implementations should 
always do bounds checking in operator[].  I disagreed with this 
(though it may not have been what you meant).  It would only be 
acceptable in so called "debug builds".

> A
> quality implementation should catch violations in debug builds.

In general I agree with this, though I prefer the Eiffel approach 
where you can fine tune this behavior.  I may want a debug build that 
doesn't check such assertions.

> It's true
> that this won't guarantee that the release build will work, but it 
will
> catch many bugs and they'll be caught early enough that they'll be 
easy to
> fix (think about how much time can be saved by an assert that 
catches a
> user scribbling past the end of an array).

Frankly, I rarely run across this error, so I don't find the argument 
as compelling as others might.  However, since it's a debug only 
thing, if it can catch one such error it's worth the extra code.

> If boost is intended to be used by many people with a wide range of 
skill
> levels shouldn't we do everything possible to ensure that the 
inevitable
> bugs are caught quickly? Assertions are an important part of this...

Depending on what assert we use, I'd agree ;).  I like the discussion 
about customizing assertion behavior.  The "standard assert" in my 
(least) favorite compiler doesn't drop you into the debugger as 
nicely as other asserts (provided by the same company) do, for 
instance.

Bill Kempf