From: Jesse Jones (jejones_at_[hidden])
Date: 2000-12-15 20:11:53
>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. A
quality implementation should catch violations in debug builds. 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).
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...
Boost list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk