Re: [boost] Re: bounds checking in array.hpp

From: Andrew Green (ag_at_[hidden])
Date: 2000-12-15 21:19:06

Just my luck that the day I switch to digest mode is also the day I felt 
moved to contribute my two bits, so forgive me if this is has been obsoleted
by other posts I haven't seen yet.

> Jesse Jones:
> A quality library should define good preconditions and postconditions

I heartily concur with Jesse's statements regarding the liberal use of
assertions in boost. My own experience is that the problems I have to fix
are the ones that are real problems, where I misunderstood what needed to be
done, rather than where I miskeyed something.
I know it can be hard or impossible to come up with conditions to catch
every possible violation of a type's constraints, but it is usually trivial
to catch the ones that you just know are going to happen most often -- where
the valid ranges of parameters are not intuitively obvious, or must match
certain magic values. The only danger with assertions that just drop out in
a release build are those that have significant side effects. Without
language support it has to be a matter of discipline that assertions have no
impact, but that's the kind of discipline I would expect boost contributors
to be more than capable of sustaining.

> William Kempf:
> 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

I don't think it's a matter of thinking one's code is safe when it's not,
but more of knowing it's bad when it actually seems to be working. Use of a
bad pointer might get caught by the debugger or OS, or it might not trip
anything up under any test scenario. But it's still a bad pointer, and it
will cause problems at some time. It came from somewhere, and an assertion
in the right place might well have indicated its imminent 'escape', a
significantly easier bug to fix than backtracking the provenance of the
pointer at its point of use.

A+