Re: [boost] [serialization] Regressions?

From: David Abrahams (dave_at_[hidden])
Date: 2005-07-01 07:53:40

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

> David Abrahams wrote:
>> "Peter Dimov" <pdimov_at_[hidden]> writes:
>>
>>> David Abrahams wrote:
>>>
>>>> [...]  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?
>>>
>>> The user of my application will do something along these lines,
>>> yes. :-)
>>
>> The /user/ of your /application/ is a programmer?  I'm sorry, but
>> could you fill in some detail here?  You're baffling me.
>
> I may not write the above fallback explicitly, but if I have menu items for 
> "Save with tracking" and "Save without tracking" and the user tries tracking 
> and it fails, he will likely try the other option.

You're not seriously proposing that a real GUI application would have
both those options, are you?  Can you really imagine an application
where either of those two strategies might be applicable?

>>> When you have a complex data structure, it isn't exactly trivial to
>>> determine in advance whether it's "tracking safe" to attempt a save.
>>> If you try to do that,
>>
>> You mean "to determine in advance...?"
>>
>>> you'll end up duplicating the save functionality.
>>
>> How?
>
> If you have an arbitrary data structure, the easiest method to determine 
> whether it's "tracking safe" is to attempt a save and watch for the 
> exception. If you try to write an is_tracking_safe algorithm, you'll see 
> that it basically follows the same pattern, except that it doesn't write to 
> an archive.

Okay.

>>> Consider something like
>>>
>>> vector< shared_ptr<A> > v;
>>>
>>> where the A is an abstract class and the implementations are put
>>> into v from separate parts of the program written by different
>>> people.
>>
>> Well, aside from not being able to deserialize deleters, I'm not sure
>> what the problem is.  In your scheme, AFAICT, a pointer save never
>> directly triggers an exception anyway.  Am I missing something there?
>
> A pointer save triggers an exception if you've already had two value saves 
> from the same address.

Oh, OK.

> The problem in the above is not in serializing shared_ptr<A>, it's that in 
> general you don't know what's behind these A's and what save sequence they 
> are going to produce. 

I understand that you're saying it's hard to control the order and
manner in which things are serialized overall, and it's especially
hard for the author of a small component to make local decisions whose
rightness can only be determined with knowledge he doesn't have.  What
I don't understand is how any program can have a reasonable fallback
strategy for the case when things go wrong, nor how a program where
things go wrong can be considered correct.  

In other words, hard as it may be, it seems to me that you have to
control the order and manner in which things are serialized in your
program, or the program just won't work.  To have a fighting chance,
you probably need to establish some program-wide policies that allow
you to know enough about how other parts of the program are
serializing things.

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