Re: [boost] [serialization] Regressions?

From: David Abrahams (dave_at_[hidden])
Date: 2005-06-29 10:00:41

"Peter Dimov" <pdimov_at_[hidden]> writes:

> David Abrahams wrote:
>> "Peter Dimov" <pdimov_at_[hidden]> writes:
>>
>>> David Abrahams wrote:
>
> [...]
>
>>>> Then it's almost impossible to write a reliable save function.
>>>
>>> It's impossible to write a reliable save function regardless of that.
>>
>> This just seems cryptic.  What do you mean?
>
> A save function can always fail; you can't write a reliable save function if 
> you use "reliable" as "will succeed".

Sure, if the save function is just doing hashing, you can ;-)

But seriously, that's not what I mean by reliable.  I mean "a save
function that's doing something sensical."  Either the author of the
save function tells the caller whether the object will be tracked, and
the caller knows whether that behavior is appropriate given the
context, or there's little point in making the save call to begin
with.  I mean, you're not going to do

       try
       {
           save_call_with_tracking(ar, x);
       }
       catch(tracking_error&)
       {
           save_call_without_tracking(ar, x);
       }

right?

> If you use "reliable" as "will not invoke undefined behavior", then the 
> exception version is reliable, the precondition version is not.
>
> I'm very surprised by this suggestion to throw on undefined behavior
> coming from you.  You can't have it both ways. Either the behavior
> is defined for the problematic cases, or it isn't. If it isn't, you
> can't expect an exception. You can't expect anything. Corrupting the
> archive beyond redemption with no warning is perfectly within the
> specification.

Well, it must've been a moment of weakness.  I never really thought
the exception was a good idea no matter how you classify the
condition.

>>>> How is the exception going to help?
>>>
>>> By detecting that this particular sequence of saves (which in general
>>> depends on the structure being saved and is a runtime property)
>>> would have produced an unreadable archive.
>>
>> An assertion can detect that, too.
>
> No, an assertion does not detect anything. An assertion is an
> implementation detail, one particular manifestation of undefined
> behavior. You can't use "reliable" and "assertion" in the same
> sentence.

Just did ;-)

Seriously, though: the assert macro in <cassert> has defined behavior.
You can definitely document that a function uses assert(x) for any
condition x; when you do that, you're invoking defined behavior.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com