Re: [Boost-users] Serialization / "Pointer conflict"

Subject: Re: [Boost-users] Serialization / "Pointer conflict"
From: Robert Ramey (ramey_at_[hidden])
Date: 2009-05-14 21:02:24

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