Boost logo

Boost :

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
> >checking,
> >> >and the operator[] form is fast and does not. While I don't
> >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
> 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

> 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
> >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
> 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
> 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
(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
> 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
> >will
> >> 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
developer. :-)

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

Bill Kempf

Boost list run by bdawes at, gregod at, cpdaniel at, john at