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" <timothysc@gmail.com> wrote in message news:ef85fd8f0711010711v55768a02s97411302423a2b2f@mail.gmail.com...
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 <christoph.duelli@gmx.de> 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]