Re: [boost] Re: any_function (callback) library

From: Jesse Jones (jesjones_at_[hidden])
Date: 2001-04-13 15:48:07

At 4:01 PM +0300 4/13/01, Peter Dimov wrote:
>From: "Jesse Jones" <jesjones_at_[hidden]>
>
>
>>  At 6:44 PM +0300 4/12/01, Peter Dimov wrote:
>>  >The options for the documented interface of a function, as I see them,
>are:
>>  >
>>  >[1] f() throws if X;
>>  >[2] f() calls precondition_violation if X;
>
>After giving this some thought, I'd add
>
>[2.5] f() uses BOOST_ASSERT(~X);
>
>where BOOST_ASSERT does the appropriate thing when BOOST_DEBUG is defined
>and is (void)0 otherwise. (BOOST_DEBUG instead of NDEBUG or _DEBUG to avoid
>ODR violations by mistake.) The "appropriate thing" should include calling a
>user handler, if installed, but should probably not include throwing an
>exception.
>
>Or perhaps we should have BOOST_PRECONDITION, BOOST_POSTCONDITION, and
>BOOST_INVARIANT.

I'd lean towards doing that.

>  > >[3] the behavior of f() is undefined if X.
>>  >
>>  >Having precondition_violation won't make the question of choosing among
>the
>>  >three magically go away, however. :-)
>>  >
>>  >Note that I think that [2] should work the same in debug or release
>builds,
>>  >with the possible exception that the default handler may do different
>>  >things. The check should not disappear.
>>
>>  If I understand you correctly you're saying that the code should
>>  evaluate a predicate and call a function which will dispatch to some
>>  handler if the predicate is false. And the function call will always
>>  be made, although the handler may be nil.
>
>Sort of. boost::precondition_violation should never return, so the handler
>may not be nil. (If it returns the library would probably crash.) It will by
>default perform the equivalent of assert(0). The only way to recover would
>be to throw an exception.
>
>Basically, the same as assert, but does not disappear in release and the
>handler may throw.

I see. I think that I would be OK with this, but I'm a bit disturbed 
that there is no way to disable the checks in release. With a bit of 
care I don't think this would be too much of a problem, but I think 
there will be a significant psychological barrier among a lot of 
C/C++ developers.

>
>>  Would you do the same with post-conditions? With invariants?
>
>_I_ wouldn't - if a post-condition or an invariant is not met, this is a bug
>in the library, not in the user code. This (hopefully) should never happen.
>:-)

Better watch for the bottom when you get on those slippery slopes! :-)

>  > What if
>>  a check isn't constant time?
>
>[2.5] or [3], I guess.

Check.

   -- Jesse