Re: [Boost-users] Using boost::serialization inreal-timewithoutallocating memory

Subject: Re: [Boost-users] Using boost::serialization inreal-timewithoutallocating memory
From: Stefan Strasser (strasser_at_[hidden])
Date: 2009-09-21 13:57:18

Am Monday 21 September 2009 19:10:15 schrieb Robert Ramey:
> Peter Soetens wrote:
> > On Fri, Sep 18, 2009 at 23:56, Robert Ramey <ramey_at_[hidden]> wrote:
> >> Peter Soetens wrote:
> >>>> That's it ! I used the wrong load/save functions. I cleaned up the
> >>>> archives and documented a bit. The only obscurity is that both
> >>>> classes required a 'save/load_object()' function, while this is not
> >>>> documented as such in the Archive Concept pages. Is this a recent
> >>>> addition (I'm
> >>>> using Boost 1.37.0 btw)
> >>
> >> This would be due to the fact that even the "trivial_archive"
> >> inherits functionality from common_?archive. The archive
> >> concept doesn't require this - but most archives will want to
> >> do this - then override the implementation of common_?archive.
> >
> > That's not my point. As I understand the 'Loading/Storing Archive
> > Concept', any archive that implements the listed functions should be
> > able to process 'ar << data;' if the serialization handler for data is
> > defined. My archive implemented the concept fully, but did not compile
> > because of a missing function. The only conclusion I can make is that
> > the concept is not complete, or violated because people only tested it
> > with the common base class and started to assume some functions were
> > there while they are not required to be.
>
> I would have to look into this in more detail to really provide an answer.
> Clearly, the fact that that "trivial_archive" inherits from common_archive
> would suggest you're correct about this or maybe that something else
> is out of whack.  I'll look into it when I have nothing else to do.  Given
> you've already wrapped your head around this whole issue - maybe
> you want to suggest how something might be changed.  My first
> approach would be to figure out why save/load object is required to
> compile.  Perhaps this is just an implementation artifact.  Ideally
> the implementation could be slightly refactored to support the
> original concept.

I think to support this an other use cases like it common_archive would have 
to be moved outside of the linked library into a header and be made more 
generic.
right now it's full-blown type-registering/object-tracking, object-graph with 
class-hierarchy serialization, or nothing - write your own archive from 
scratch.
I've also had my problems with that. although I didn't have to avoid 
allocation completely, the construction of a common_archive took too long and 
you couldn't configure away the parts you don't need.
such a generalization could be based e.g. on what is described as "levels of 
sophistication" of serialization, here: 
http://www.parashift.com/c%2B%2B-faq-lite/serialization.html#faq-36.2