From: Brian Braatz (brianb_at_[hidden])
Date: 2005-04-19 10:47:25
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
> -----Original Message-----
> From: boost-bounces_at_[hidden]
> On Behalf Of Jarl Lindrud
> Sent: Sunday, April 17, 2005 11:47 AM
> To: boost_at_[hidden]
> Subject: [boost] Re: Proposal: Design by Contract / Pre
> 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
> > variables they want to be displayed in the error message?
> The user just states which variables he'd like to see printed, if the
> 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
> > 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
> > shouldn't
> > > borrow the name "Design By Contract", since that implies a
> > external to
> > > the function. Proper DbC contracts need to be stated at the level
> > function
> > > declarations, and would apply to overrides in derived classes as
> > Point taken.
> > Originally I was hoping to add invariants etc., but I didn't get to
> > Of course, even with invariants it will still be more at the
> > In general, I think there's a lot to do (temporal invariants as in
> > ", for example)
> > and since it is so useful (a fact I discover every time a condition
> > code is invalidated)
> > it think, IMHO, it should be a library for all to use and for many
> > contribute to.
> Agreed. Formalizing the PRECONDITION and POSTCONDITION macros would be
> useful, I think. But I wouldn't be too worried about trying to emulate
> that's a different concept altogether.
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk