Pfligersdorffer, Christian wrote:
Hello Robert, hello all,
I know it is stated in the boost::serialization library documentation that per definition always the latest version of a class goes to the archive. I wonder if there is a way to change this behaviour and choose the version number for my class at runtime. Obviously this feature would be useful in a system of two dependent modules where either the producer or the consumer could by updated to a newer version without the other one being neccessarily updated too. Maybe this has already been discussed but I could not find anything about it on the web. However my strong suspicion is that there is no such option within the library and I will have to provide a solution within the affected classes.
I dismissed this issue when it was recently brought up for the first time. I had never intended to provide an option for making "backward compatible" so I had presumed that it wasn't going to be possible. Well, some people kept bugging me and I did a little investigation and found that it would be quite possible with just a little bit of tweaking - and an amplified section in the documentation. So I guess it will be done with 1.35. FYI, the reason its doable is just a side effect of the fact that I leaned hard on "symetry" (I know I'm an atrocious speller) in order to conserve brain surface area. I suppose there is a lesson in there somewhere.
Another thing: I specialize boost::archive::detail::heap_allocator<T> for my types to use my own memory management :-) Any objection to that?
The truth is I never really considered issue related to custom allocators. I'm particularly interested in serialization of collections which use custom allocators. So I'm interested in any experience in this area.
Finally I want to thank Robert Ramey for his fabulous library and his always timely and helpful answers. I think from the user perspective he stands as a positive example for others.
I'm glad it's appreciated. But I should say that I really enjoy spending time on these kinds of posts. I guess its the smart persons alternative to internet chat forum. I would like to encourage those with questions/experience like this to get a little bit more involved in contributing to boost. Consider it therapy for a day job where you spend all day with brain dead managment and spend all your time hacking up the next fix because "we don't have time" to do it right. or... I would like to see more users contribute to demos/tests to the "case studies" section of the serialization documentation. A number of ideas have been presented on this list but I don't have time to persue them all. Here are a few. a) serialization of collections with custom allocators b) serialization of function objects c) automatic generation of an archive editor - (actually I've made progress on this myself) d) backward compatible archives - will require tweak in library but also special practice for serialization functions. e) composition with special stream buffers for increasing speed, implementing compression etc. What's in it for you? You get full authorship credit on your case study. It looks good on your resume. It makes you a part of the world's most exclusive club of C++ programmers. You get the satisfaction of knowing that you've done something "almost perfect". You get the satisfaction of knowing that perhaps thousands of other programmers know, use and appreciate your work. In short you get almost all the satisfaction that goes with being an "official" boost developer without the real pain (dealing with bjam, build, etc.) Rather than suffering a review process which is really frustrating, public and often unpleasant, you only have to pass one reviewer (me) in private. You get to interact with people who work with your code and get a chance to tweak it from time to time to fix bugs, clarify documentation, etc. In short you get most of the satisfaction of being a boost developer and avoid most of the pain. (Of course to get the full boost experience you have to undergo the full pain of a review and all the rest - but most people don't have the time for that) So there you are. Robert Ramey