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

From: Jesse Jones (jejones_at_[hidden])
Date: 2000-12-18 18:41:32

>> 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.

I should have been more precise. I was talking about an assert replacement.
BOOST_ASSERT or whatever it will(?) be called.

>> 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.
>
>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 :(.

I'd rather not go there. :-)

>> 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.
>
>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 pretty common for one public method to call another even when the
object doesn't strictly satisfy the invariant. There's usually nothing
wrong with the code, but it's awfully annoying to have to weaken your
contract for these occasionaly cases.

  -- Jesse