Jarl Lindrud wrote:
Robert Ramey <ramey <at> rrsd.com> writes: Hmmm. This implies that the meaning of the code "ar << t" , depends on the content of the entire program.
I would agree that the implementation of ar << t depends upon the content of the entire program.
Note that this has the counter ituitive effect of seeming to "look ahead" in the code.
What's worse is that it also seems to "look across" :)
Just remember this: If each load must use the exact same type as each corresponding save.
If you follow this rule, you will never have a problem of this nature.
Let me sum up what it is that worries me. Say I have program A, with this kind of code:
std::ostringstream ostr; boost::archive::text_oarchive(ostr) & v0;
std::istringstream istr(ostr.str()); boost::archive::text_iarchive(istr) & v1;
bool ok = (v0 == v1);
, and nothing else. Say that I also have another program B, with the same kind of code, that reads archives produced by program A.
Everthing is working well. And then in program A, at a later stage, some more code is added, containing these lines:
ar << pVec; // pVec is a vector<char> *
, and
ar >> pVec; // pVec is a vector<char> *
Perhaps the code is not even executed. Now, program A still functions. It can read the archives that it has produced *but* the archives now, IIUC, have a different format. So when program B tries to read the archives, it will fail, and may well fail silently.
True. But note that this is not the case which brought up the discussion.
So essentially addition or modification of code, *anywhere* in program A, and regardless of whether it is executed, can cause a runtime failure in program B! You can imagine how difficult this would be to debug.
Default tracking is "track_selectively" and default implementation level is "? - include class information in the archive. You might want to change the implementation level for your classes to "track_always".
Wouldn't it be easier if serialization settings like tracking_level were set by the user, explicitly at runtime? That way one could set it exactly as one wants it, rather than having to guess at the side effects of compile-time instantiations throughout the entire program.
Actually, I see a lot of merit in this argument. In fact the whole concept of "serialization_traits" is amounts to a global table keyed on data type. So it does have the same problem - ie side effects that any global table does. It's not as bad a normal because it doesn't change dynamically but it can still be a problem. On the other hand, having to explicitly specify these traits for each invocation of ar << ? and ar >> ? would be very tedious and I dare say unpopular. And likely prone to other kinds of errors. You might make a more convincing case that tracking traits should not include "track_selectively". Or maybe the ALL types should have their class information stored in the archive. I'm sure that many people would then complain about efficiency. It would be possible for someone who had nothing else to do to re-implement and enhance the Archive templates with a policy to explicitly use a specific tracking or implemention level regardless of the "traits setting". I've actually considered using such a method to suppress All tracking for the whole archive. This would permit using the serialization system for things Error logging, transacction processing, etc. Note that doing this would not require changing any of the archive or serialization concepts so it would be applicable "for free" to an program which already had serialization implemented. Serialization turns out to be a far richer subject than first meets the eye. Robert Ramey
Regards, Jarl.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost