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
> >> >and the operator form is fast and does not. While I don't
> >> >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
> disservice to their users by releasing libraries with so little
*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
> 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
> 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
> >doesn't check such assertions.
> Ideally I'd like to see an assert macro with user defineable
> explicit support for design by contract (ie
> macros and invariants). Apart from the ODR problem the assert
> 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
> and strengthen postconditions. I'm not sure how this would be done
> 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
> invariant is only checked on entry and exit from a public routine).
> pretty nice. In my experience it's fairly common for an object to
> temporarily fall into an invalid state and then call another public
> This is doable but requires that a counter be added to every object
> 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
> >> catch many bugs and they'll be caught early enough that they'll
> >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
> >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
*laughs* Only at insuring static pre- and post- conditions are met.
I make more than my share of other mistakes.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk