In general, one has to load anything in the same way it was saved. so if you class Foo *foo; ar << foo you better class Foo *foo ar >> foo Anything else will likely fail. Of course, it's easy to make a mistake. I recommend: a) prefer ar & foo over ar<< and ar >> foo b) if your code fails, serialize to an xml_archive. This includes code for matching the start/end tags expected and will usually detect errors. Robert Ramey Dan Eaton wrote:
Hi all,
Sorry for my last question; it was posted hastily -- I subsequently found the Reference->Special Considerations->Optimizations section.
Anyway, I have a new problem/question:
It's somewhat similar to the "pointer_conflict" example:
template<class T> void save(T t) { // create stream & output archive "oar" ar << t; // send with mpi/asio }
template<class T> T load() { // retrieve string with mpi/asio T tmp; // create stream & input archive "iar" iar >> tmp; return tmp; }
My problem (a few hours of debugging) was that on one end, I was passing in a pointer to an object:
FooClass *foo; save(foo)
and on the deserialization end, I was requesting an object:
FooClass foo = load<FooClass>();
My mistake only showed up through the "array_size_too_short", since as part of the deserialization of FooClass, a fixed-length array was being deserialized, and I guess wonky parsing resulted in "count" being larger than "current_count" in iserializer.hpp.
Is what I was doing dangerous, or should/can the boost::serialization library somehow catch that mistake (i.e. in the serialized string, cant it not detect that the object is a pointer to an object, even if it's unregistered)?
My fix is to disallow the serialization of pointers on the forward side:
if( boost::is_pointer<T> ) throw exception
Thanks in advance for any thoughts you might share on the matter,
Danny