David Abrahams wrote:
"Peter Dimov" <pdimov@mmltd.net> 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.