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

From: Jeff Paquette (paquette_at_[hidden])
Date: 2000-12-18 16:58:24

Where I work we have three basic assertion macros for  design-by-contract:
Assert, Require, and Ensure. Require's are for preconditional checks, Ensure
are postconditions, and Asserts are for algorithmic checking (ie, in-process
states).

We also have conditional forms: AssertIf, RequireIf, EnsureIf that perform
the assertion iff the condition is true. For instance:

SomeClass *p;

AssertIf(p, p->SomeCheck());

AssertIf is defined as follows:

#define AssertIf(_cond_, _exp_)   Assert(!(_cond_) || (_exp_))

where Assert is our customized assertion handler (dialog in gui mode,
individual assertion suppression, drop into debugger, ignore, throw etc.).

If anyone would like more information, drop me a line.
--
Jeff Paquette
paquette at mediaone.net
http://www.atnetsend.net
> -----Original Message-----
> From: Jesse Jones [mailto:jejones_at_[hidden]]
> Sent: Monday, December 18, 2000 4:49 PM
> To: boost_at_[hidden]
> Subject: Re: [boost] Re: bounds checking in array.hpp
>
>
> >> >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
>
>
>
>
>
>