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

From: Jesse Jones (jejones_at_[hidden])
Date: 2000-12-18 16:49:23

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

Basicly I'm not happy with how things stand. IMO vendors have done a real
disservice to their users by releasing libraries with so little debugging
support. Also the behavior of assert in release builds should exactly match
the possibilities of assert in debug builds. Most people will probably want
to define them away, but there will always be a few who will want to exit
or throw.

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

Ideally I'd like to see an assert macro with user defineable behavior and
explicit support for design by contract (ie precondition/postcondition
macros and invariants). Apart from the ODR problem the assert should be
pretty easy. DBC is tougher. Eiffel automatically checks base class
conditions inside subclasses and allows subclasses to weaken preconditions
and strengthen postconditions. I'm not sure how this would be done without
language support.

Eiffel also disables invariants while an object's method executes (ie the
invariant is only checked on entry and exit from a public routine). This is
pretty nice. In my experience it's fairly common for an object to
temporarily fall into an invalid state and then call another public method.
This is doable but requires that a counter be added to every object with an
invariant. I currently do this with a mixin class.

Once you have precondition and postcondition macros you have a bit more
room for fine tuning...

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

I suspect you're a wee bit better than your run of the mill developer. :-)

  -- Jesse