[boost] Re: Proposal: Design by Contract / Pre & Postconditionslibrary

From: Yariv Tal (yariv_tal2003_at_[hidden])
Date: 2005-04-17 11:07:28

Hi Jarl,

"Jarl Lindrud" <jlindrud_at_[hidden]> wrote in message
news:loom.20050417T153708-646_at_post.gmane.org...
>
> Yariv Tal <yariv_tal2003 <at> hotmail.com> writes:
>
> >
> > Is there a need for a Design by Contract (a.k.a Pre & Post conditions)
> > library?
>
>
> I tried to write something like this a while ago: http://www.codeproject.
> com/cpp/DesignByContract.asp .
I took a look and really liked the syntax and the error messages.
I think that storing the values of used variables in order to show them in
the condition failure message is a great idea.
Do you check at compile time that the used gave all of the variables
participating in the expression or do you just let the user state which
variables they want to be displayed in the error message?

One thing though, I didn't see any handling of disabling testing post
conditions when
an exception is thrown.
Did I miss something?

>
> How much impact do your macros have on compile times? I found that the
lambda
> expressions used to implement postconditions really took a toll on compile
times
> with Visual C++ 7.1, and on other compilers, gcc for instance, its
probably even
> worse.
The compile impact isn't small. Probably similar to the one you encountered,
although
braely use any lambda code in the implementation, so it's as heavy as the
user makes it
(they can always choose to write an explicit functor or use the std functor
manipulators,
I guess...)

>
> Since these macros are part of the function implementation, maybe one
shouldn't
> borrow the name "Design By Contract", since that implies a contract
external to
> the function. Proper DbC contracts need to be stated at the level of
function
> declarations, and would apply to overrides in derived classes as well.
Point taken.
Originally I was hoping to add invariants etc., but I didn't get to it.
Of course, even with invariants it will still be more at the function level.
In general, I think there's a lot to do (temporal invariants as in "keystone
", for example)
and since it is so useful (a fact I discover every time a condition in my
code is invalidated)
it think, IMHO, it should be a library for all to use and for many to
contribute to.

>
> Trying to simulate DbC through macros is a battle waiting to be lost, I
think.
You are right, but I find even a limited implementation is powerful enough
to be
useful.

> I'd be more interested in a good POSTCONDITION macro, that works like an
> assertion, except that it kicks in when leaving the surrounding scope.
Then
> people can do whatever they want with it, including rudimentary "DbC".
Its in there. Take a look at the second example.
(only problem is that it requires the compiler to support
uncaught_exception).

>
> My $0.02.
Glad to have read them.

>
> /Jarl.
>

Yariv.