Have you considered this any more? I understand the issue but I'm not convinced that your fix is the best one. This would permit code for serializaton of the same type to reside in different DLLS with out the guarentee that all the code is the same. Also, I'm not conviced that our system of purging global map entries when a DLL containing serialization for a type is unloaded wouldn't create problems. That is I'm not sure that purging all the entries for a given type will be the right thing to do. I'm thinking that the best would be to detect the case when a duplicate extended_type_info record is added to the corresponding global map and throw an exception. I see no other way at this point to guarentee that the system will always work. Robert Ramey martin.ecker@tab.at wrote:
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.