On Mon, 22 Feb 2010 09:57:58 -0800
"Robert Ramey"
The change was made to make the system more robust and portable. Other changes were made to suppress warnings which indicated potential problems.
I understand that ints as such are not portable.
Your system presumes that an int is 32 bits.
Well, to this day and age, we assumed it was at least 32 bits. An unfortunate mistake...
This assumption would make otherwise portable archives not portable to C implemenations whose int is 16 bits. The version # was always assumed to be exactly that.
Are such platforms so widespread nowadays? And using boost libraries? Besides, I would assume making version_type a typedef for uint32_t instead would work everywhere, if inducing some overhead on 16-bits cpus?
I didn't anticipate that this might be overloaded with some other data - like a date. Had this occurred to me, I would have advised against doing this in them documentation.
I would not call our scheme "overloading". We still use these as version numbers, increasing with each new alteration of the classes, independantly for each class. Instead of dates, we could have used code-wide version numbers, ala subversion. All we needed was numbers representing a single point in time globally for all of our classe. Using this kind of numbering has several maintenance advantages, or so I think. For example, our early releases did not use versioning at all, since this simply was not a requirement initially. So we have old archives specifying 0 for the version of all their classes. A couple of releases later, we introduced backward compatibility at our clients demand (some of them clung to old releases just to be able to reuse their old archives). To this end, our load() methods contain code similar to this : template<class Archive> void load(Archive& ar, SomeClass& o, const unsigned int v) { unsigned int version = v; if (version == 0) version = archive_creator_release_version; if (version >= 20080517 && version <= 20080903) ... } where archive_creator_release_version is the date at which we released the software that generated the archive we're trying to reload (this is saved at the beginning of every archive). To write the compatibility reloading code, we only need to look at our code repository history, and add some of these special-cases to our load() methods. If we did use "classical" version numbers, this would have been very difficult to do (at the very least, we would need to store a map of the versions used for each class for each of our releases, and use that when encountering an archive with a 0 version). And a single mistake in a release would have been a lot more difficult to fix afterwards. What do you do when you discover that there are in fact archives which used a variant of SomeClass between version 4 and 5? Anyway, using the release date as the default version for all classes when reading back old archives proved very usefull. There are other cases were using dates as version helped maintain our code, but this message is too long already, and I'm not sure I explained the first case clearly enough ...
I realise that this is of cold comfort to you. Here are some ideas.
a) You could tweak your copy of the library to use a 32 bit integer.
Doable, but inducing difficult constraints. We'd really prefer that our clients be able to link to both official boost releases, and our libraries at the same time. We link dynamically to boost for that reason.
b) in the longer run, you could decline to use the versioning built into the system and substitute your own based on dates. This would entail tweaking all your serialization implemenations to save your "date version" as part of the data.
That would be an awfull lot of code rewriting, and would not help with reading back old archives unfortunatly.
Sorry I can't be of more help. Moral of the story is "Overloading data leads to unanticipated consequences"
I did not realize the unsigned int version was intended to be 8 bits, or I would not have done that. Too late now. Hopefully there is another way out we did not think of yet... Thanks for your response in any case, -- david