-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Jarl Lindrud Sent: Sunday, April 17, 2005 11:47 AM To: boost@lists.boost.org Subject: [boost] Re: Proposal: Design by Contract / Pre &Postconditionslibrary
Yariv Tal <yariv_tal2003 <at> hotmail.com> writes:
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?
The user just states which variables he'd like to see printed, if the condition were to fail, and its fine not to specify any variables at all.
One thing though, I didn't see any handling of disabling testing
General 2 cents: About a year ago I built a library for internal use along the lines being discussed in this thread. (for the curious what I did was hook logging and tracing to the Precondition and postcondition) After I got it all done, I said to myself, OK I am now going to USE this code and abide by it's rules. I found that very difficult to do, because of my OWN difficulties in doing that I have shelved this library for our internal usage. (i.e from a practical nature it would be hard to get people (myself included) to continue to use it) I ask the people thinking about this lib, to sit down and try to write 10 or so functions and get a sense for if you would actually USE it. I am not trying to be a downer, more I am sharing my experience. There may be a place for this lib in the same regard as scope guards are used. Scope guards are nice when you need them, but you don't need them everywhere.... post
conditions when an exception is thrown. Did I miss something?
No you didn't... guilty as charged :)
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.
Agreed. Formalizing the PRECONDITION and POSTCONDITION macros would be quite useful, I think. But I wouldn't be too worried about trying to emulate DbC, that's a different concept altogether.
/Jarl.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost