|
Boost : |
From: David Abrahams (dave_at_[hidden])
Date: 2003-10-11 07:08:57
"Rainer Deyke" <rainerd_at_[hidden]> writes:
> David Abrahams wrote:
>> That may be true, but I don't think so. The idea of a special
>> error-only singular state makes me nervous. It means that you always
>> need to be aware of every bit of code where you might be dealing with
>> the singular state, and those conditions can change in ways that break
>> encapsulation. For example, if you write a function which ignores the
>> possibility of the singular state, because you know you're only using
>> it on "good" objects. Then one day you find you want to use the
>> function in some destructor... but that might get invoked during stack
>> unwinding from an exception that throws the very object in question
>> into its singular state. insidious, isn't it?
>
> Such a function would need the following properties:
>
> 1. Passing in an arbitrary non-singular variant causes no ill side effects.
>
> 2. Calling it with a a singluar variant does cause ill side effects.
>
> 3. It is somehow useful to call this function with garbage input.
>
>
> I am not convinced that such a function exists. I'm particularily skeptical
> about requirement 3.
I'm going to answer this one as a kind of clarification of my
position: when you're trying to write safe code, the question of
utility is not so important. What's important is trying to put some
bounds on what you know the state of the program to be.
Another way to put it is: you want to be sure you know what *can*
happen. Recall Murphy's law.
Turning an impossibility into something that can only be prevented
with runtime checks makes it harder to reason about the program state.
-- 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