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
> >> >methods are used. I think it would be a great boon to the
> >> >using boost if there could be a debug mode -- either use
> >> >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
> >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.
> The standard says that at() must throw if the precondition is
> that the behavior of operator is undefined. It's true that most
> do a poor job of catching precondition violations, but there's no
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk