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

From: David Abrahams (abrahams_at_[hidden])
Date: 2000-12-16 20:38:45

----- Original Message -----
From: "Andrew Green" <ag_at_[hidden]>

> Just my luck that the day I switch to digest mode is also the day I felt
> moved to contribute my two bits, so forgive me if this is has been
obsoleted
> by other posts I haven't seen yet.

FWIW you can always read the latest messages off the web at egroups if
you're so moved.

> I don't think it's a matter of thinking one's code is safe when it's not,
> but more of knowing it's bad when it actually seems to be working. Use of
a
> bad pointer might get caught by the debugger or OS, or it might not trip
> anything up under any test scenario. But it's still a bad pointer, and it
> will cause problems at some time. It came from somewhere, and an assertion
> in the right place might well have indicated its imminent 'escape', a
> significantly easier bug to fix than backtracking the provenance of the
> pointer at its point of use.

I agree with this wholeheartedly. When preconditions can be checked
reasonably efficiently, asserts are an excellent way to do it. A user who
can't afford checking can always define NDEBUG.

Even better would be a "hookable" assert for which the user could supply a
replacement behavior, e.g. drop into the debugger, throw an exception, log a
message, etc. There are usually ways to do this with the standard assert()
macro, but they involve unsavory practices like:

// file: cassert
// put this in your #include path ahead of the standard library
#ifndef MY_CASSERT
# define MY_CASSERT
# include <../include/cassert>
# undef assert
# define assert ...<your definition here>
#endif

Regards,
Dave