Robert, Thanks for your swift reply. Robert Ramey wrote the following on 2/3/2007 1:30 AM:
a) catch the archive exceptions and display an error message which describes what kind of exception has been thrown.
I did something similar, but it is still a poor workaround. I save data incrementally and rotate savefile names to make sure the player does not lose all data, but just the changes since the last increment. Still, losing all game progress since the last savefile increment is a major turnoff for most players.
b) Set your debugger to trap when the exception is thrown and look at the source code at that spot. This should contain some extra info about why the library is unable to proceed.
Usually this is indeed helpful, but in this case the boost source code was too cryptic for me to understand the problem.
c) Just a while guess - thrown from load binary might suggest either the file isn't being opened binary, or the size of data being read isn't the same as what's being saved.
I doubt that since there is only one save and one load routine in my application. If I opened the file as text when saving and as binary when loading this would always fail. But in my case everything is working fine most of the time.
d) Sometimes this can occur when the save/load serialization is "out of sync". that is the save and load are not code symetrically. This might occur due to a program change without the use of versioning. It is sometimes helpful to save/load with xml_archive just to double check. The serialization library archives for xml actually check the xml tags so that if something is out of sync it is detected immediatly.
This happens with the same executable, and I have not changed the format of the data being saved (i.e. amount and order of variables) so "out of sync" problems seem very unlikely here. Thanks, Adrian Grigore