At Sunday 2005-04-17 09:07, you wrote:
Hi Jarl,
"Jarl Lindrud" <jlindrud@hotmail.com> wrote in message news:loom.20050417T153708-646@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
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
lambda 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"