Boost logo

Boost :

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
> >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
> >code is safe when compiled in release mode. For this reason, I'm
> >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

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

> >This is standard for all STL containers. The at() form does bounds
> >and the operator[] form is fast and does not. While I don't object
> >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
> 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
> levels shouldn't we do everything possible to ensure that the
> 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

Bill Kempf

Boost list run by bdawes at, gregod at, cpdaniel at, john at