Robert Ramey wrote:

First of all, any failure to read any archive created under a previous version of the library is a bug. Thanks for pointing this out.

Thanks for your interest. Since my last post, I have verified that the problem was indeed fixable (or rather, circumventable) by adding an "item_version" tag where it was missing. I'll explain more below.

This is likely fixable, but we would need a little more information.

I'm sorry if my first description was vague. I'll try to be more precise, but I'm afraid I'm quite unfamiliar with the boostian terminology!

a) I'm not sure what version 4 and version 5 refers to - expand upon this.

OK. At the beginning of a serialized XML file, after the "

b) I'm not sure what type the "item_version" refers to. Is it the list type or (more likely) the type which is being pointed to. c) what type is being pointed to?

Well, I can't say I'm positive either! Basically, the relevant part of my type structure looks like this: //BEGIN_CODE class Component { ... }; class CompA : Component {...} class CompB : Component {...} class CompC : Component {...} class Object { ... std::map name_comp_table; std::vector interesting_comps; }; //END_CODE Basically, I serialize instances of Object. The interesting_comps member holds pointers to Components that already exist in name_comp_table. The CompX classes are what actually stored in Objects using pointers to their polymorphic base class Component. It is in the serialization of the interesting_comps member of the Object class that this possible bug happens. Since all the objects pointed to by the elements of the interesting_comps vector are already serialized, the serialization system (rightfully) just stores an "object_id_reference" in the file, like this: //BEGIN_DATA ... <count>10</count> <item class_id_reference="13" object_id_reference="_13"></item> <item class_id_reference="15" object_id_reference="_14"></item> <item class_id_reference="16" object_id_reference="_15"></item> <item class_id_reference="17" object_id_reference="_16"></item> <item class_id_reference="17" object_id_reference="_17"></item> <item class_id_reference="17" object_id_reference="_18"></item> <item class_id_reference="17" object_id_reference="_19"></item> <item class_id_reference="19" object_id_reference="_22"></item> <item class_id_reference="20" object_id_reference="_23"></item> <item class_id_reference="21" object_id_reference="_25"></item> ... //END_DATA I think the above lacks an "item_version" tag after the "count" tag. Like so: //BEGIN_DATA ... <count>10</count> 0 <item class_id_reference="13" object_id_reference="_13"></item> ... //END_DATA In fact, I wrote a script that went through all my serialized XML files, checked whether this "item_version" tag existed or not, and added it if it didn't. This solved my problem completely and now the files load as they did before. Also, I found out that the example I gave you above was the only place that this wrong behavior happened (I have several hundred of these Objects per XML file on average, and this happened in all of them and nowhere else.) I also use serialization for several other STL containers, including vectors and maps, but none of them contains pointers to previously serialized data and none of them behaves erratically. I can post real header files and real serialized data if you want, but I doubt they'll be useful to anyone due to excessive noise. I may be able to reproduce the problem using simpler data structures if really needed (however, since my immediate problem is solved and due to a tight schedule in this project, that may take a few days.)

d) can we assume no changes in the serialization traits?

I guess so. During these tests, I did not touch any of my own code. I only replaced older Boost header and library files with freshly checked-out and built ones.

Robert Ramey

Again thanks for your time and interest. -yzt