Re: [Boost-users] [serialization] Writing an old version of a class

From: Pfligersdorffer, Christian (Christian.Pfligersdorffer_at_[hidden])
Date: 2007-08-08 03:37:28

Hello Robert!

Robert Ramey wrote:
> 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.

That's good news. I suppose it should be doable since everything you
need is there - solely the option to pass a version number to the
serialize functions. I wonder how you would add that feature without too
many changes to the user interface. Since that relies on streaming
operators maybe stream manipulators? Or archive member functions? I am
interested in the details! :)

>> 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.

I might contribute our scenario which is serialization of command
objects and for deserialization iterating over them using a custom
allocator. Actually I think that would be fun although in the moment I
am working to full capacity given my day-job and that paper I should be
doing. So I will see what I can do during the next months and come back
to you for it.

> 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) 

As I said, it sounds fun :)

Regards,
Christian Pfligersdorffer