Date: 2005-08-13 07:09:33
Boost.Serialization 1.33.0 breaks serialization of derived classes
referenced via base class pointers when using DLLs on Windows and VC
7.1. It might also affect shared objects on Unix, but I'm not sure how
the various Unix loaders handle multiple instances of the same
template member function in multiple shared objects.
In particular what happens is that objects that are serialized via a
base class pointer are no longer deserialized correctly when
deserialized in an application that uses the DLL (and not within the
DLL itself). Instead they are deserialized as NULL pointers.
The problem is that the virtual equal_to and not_equal_to member
functions were removed from the extended_type_info base class. These
functions were previously used by extended_type_info::operator == and
extended_type_info::operator !=. Now operator == simply performs an
equal check on the address of the extended_type_info object, whereas
the previous version that used equal_to actually did a full compare of
the stored type info keys.
If DLLs are used and the DLLs themselves contain serialization code
and BOOST_CLASS_EXPORT macros, this will fail because the
extended_type_info objects are always static objects allocated on the
stack of a member template function, e.g. in
In a DLL situation this will cause multiple DLLs that include the
header file with that template function to have multiple (i.e.
separate) copies of that extended_type_info object. Thus, comparing
them only via their addresses leads to disaster.
The fix is easy. Simply put the old code for extended_type_info::operator
and extended_type_info::operator != back in.
Note that I haven't looked any further if there were other changes
made to the code that also rely on the addresses of equal
extended_type_info objects to be the same. This will also break
serialization code in DLLs. I can only say that after I put the old
code back in, our system could deserialize its data properly again.
Phone: +43 7229 78040-218
Fax: +43 7229 78040-209
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk