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

From: Victor A. Wagner Jr. (vawjr_at_[hidden])
Date: 2005-04-17 11:26:53

At Sunday 2005-04-17 09:07, you wrote:
>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?

I assumed (dangerous, I know) that NO post conditions would be tested on 
exception but those explicitly done in the exception stuff. (maybe they all 
will be if NO exception conditions are mentioned? like a default 
constructor being built by the compiler).

> >
> > 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.
>
>
>
>_______________________________________________
>Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Victor A. Wagner Jr.      http://rudbek.com
The five most dangerous words in the English language:
               "There oughta be a law"