From: Peter Dimov (pdimov_at_[hidden])
Date: 2005-07-01 04:56:01
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.
>> 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.
>> 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.
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.