"Peter Dimov" <pdimov@mmltd.net> writes:
David Abrahams wrote:
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?
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.
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?
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? -- Dave Abrahams Boost Consulting www.boost-consulting.com