Re: bounds checking in array.hpp

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-12-18 17:26:59

--- In boost_at_[hidden], Jesse Jones <jejones_at_a...> wrote:
> >> >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.

*shrugs*  I've used both varieties (MFC is heavily littered with 
asserts) and personally have rarely needed this level of support.  
Other than this probably lucky personal experience, I agree with this 
sentiment.

> Also the behavior of assert in release builds should exactly match
> the possibilities of assert in debug builds.

This is not possible using the C/C++ provided assert macro.  It would 
violate the standard.

> Most people will probably want
> to define them away, but there will always be a few who will want 
to exit
> or throw.

Very few, IMHO, but I agree.
 
> >> 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.

Try impossible with out language support or pre-processing.

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

Pre-processing can be done effectively.  There was a project that did 
this with C on the *nix platforms (don't recall the project name).  
It would be nice to have such a pre-processor for C++.  I think this 
is outside of the scope of Boost, however :(.

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

I wouldn't think it would be too common, but I agree that it can 
occur.  I think situations like this can lead to bugs, so would avoid 
such idioms when ever possible.  However, this behavior could be 
easily done using the pre-processor, though it would require extra 
data as you pointed out.

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

*laughs*  Only at insuring static pre- and post- conditions are met.  
I make more than my share of other mistakes.

Bill Kempf