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
We also have conditional forms: AssertIf, RequireIf, EnsureIf that perform
the assertion iff the condition is true. For instance:
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 > > > > > >
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk