From: Robert Ramey (ramey_at_[hidden])
Date: 2005-08-13 10:48:48
As usual a very complete analysis from martin ecker. Its amazing to me that
you can understand things at this level of detail.
I had concluded that there would never be more than one instance of a
extended_type_info object created for the same type. So it would be more
efficient to just compare the addresses. Now I see (I think) how this
assumption can be wrong. I don't see an easier fix than putting back the
I would like to add a couple of new tests to test this kind of thing. You
don't have anything suitable for this do you?
> 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.
> Best Regards,
> TAB Austria
> Haiderstraße 40
> 4052 Ansfelden
> Phone: +43 7229 78040-218
> Fax: +43 7229 78040-209
> E-mail: martin.ecker_at_[hidden]
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk