From: David Abrahams (dave_at_[hidden])
Date: 2003-11-01 16:30:37
"E. Gladyshev" <egladysh_at_[hidden]> writes:
>> I think yes, but only to the minor extent suggested above.
>> Looking at the bigger picture, I think the point is that, while theory
>> about class invariants can be useful both to help you choose a
>> representation type, and to think about pre/post-conditions on methods
>> in the public interface, this theory will not help you in the middle of
>> a method body. During the execution of a method, you can break
>> invariants as you see fit, provided things are all patched up again by
>> the time execution gets back out to client code. As a result, in the
>> middle of a method, you just have to "do the correct thing"; there
>> aren't necessarily any explicit invariants around to help you out.
> If you can break invariants practically at will internally
> and most of the time we spend implementing "internal" methods,
> then what about "don't pay for what you don't use" concept.
I don't see any relationship between the "don't pay for what you don't
use" concept and the idea of invariants.
> I was wondering if anybody on this board use
> basic guarantees *explicitly* in their design
> and/or implementation and how?
I don't understand the question. I use the basic guarantee by
knowing that a component which offers it will not break when an
exception is thrown. In other words, the basic guarantee keeps me in
my chair programming instead of giving up and going home.
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk