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