Personally I would not use this approach. To some extent
it can be seen as a matter of taste. I prefer to spend effort
in finding, fixing, and preventing the source of the problem.
So if there is an easy mistake to make which makes archives
which cannot be loaded, I would be interested in hearing
about it. I have considered making and "archive adaptor"
which would add redundent data to an archive to detect
save/load mismatches, editing of archive data outside
the serialization system and things like that. Also we
might add and "archive class" key to the header so
that an attempt to read the archive with the wrong
code would be detected. Of course, if this is a big
problem at your installation, it would be easy to add
a string at the start of each archive which specified
the class name of the archive creating it and
checks the class name of any archive being loaded.
Just some ideas for cases where it might be difficult
to guarentee that the loading archive class isn't
compatible with the saving archive class.
But I have to confess that I don't see this as a big problem.
And I don't think its something that the library can solve.
Robert Ramey
"Tim St. Clair"
I've encountered the same issue(s) in the past where signals will be raised when the data serialized is nothing close to what is expected.
I have been able to deal with it is by doing one, or all, of the following:
Derive all types which are "Serializable" from common base, then always try to unserialize to<->from that base. From there, switch/vector on the derived type, either through RTTI or some other mechanism. I would also recommend overloading the sig_hdlr, so you can gracefully shutdown in case something runs-a-muck.
Hope this helps, -Tim
On 11/1/07, Christoph
wrote: I am experimenting with Boost.Serialization. I tried to de-serialize a (binary) file written for a *different* class. Obviously, this can not work.
However, there is not thrown an exception. Question: (How) can I determine that the reading failed? (In case of corrupted or non-matching archives.)
(I have attached a small demo.)
Best regards Christoph
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
-- Regards, Timothy St. Clair [timothysc@gmail.com]