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

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
everywhere....

> -----Original Message-----
> From: boost-bounces_at_[hidden]
[mailto: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
> &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
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