Re: [Boost-users] Using boost::serializationinreal-timewithoutallocating memory

Subject: Re: [Boost-users] Using boost::serializationinreal-timewithoutallocating memory
From: Stefan Strasser (strasser_at_[hidden])
Date: 2009-09-21 15:24:45

Am Monday 21 September 2009 20:27:59 schrieb Robert Ramey:
> Stefan Strasser wrote:
> > 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.
>
> common_archive is a template - it's not in the linked library.

ok, I must have mixed up some types. the point was that the ultimate base 
class, that handles the type registration and object tracking etc., is 
linked .cpp and not very configurable.
the optimum case imho would be that you could pass a traits class to that 
archive base class, that gets called whenever there is an object or type to 
be registered and is queried for existing objects and types later on.
that way you could disable registration, save type registration outside of the 
archive itself, let type registration span multiple archives etc, make sure 
type registration doesn't allocate etc.

> I would like to see improvements in this area.  Mostly this is because
> I would like to see the library more "formal" and hence with less bugs,
> more robust, and more extensible.  It's not been a huge priority since
> most users find the the archive classes included in the package seem
> addequate to their needs.

sure, it's the best serialization solution I know and the template technique 
trumps any reflection based solution (even if c++ had reflection).
this is not meant as a critique.

>
> > 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
>
> I looked at this and found it to be very unhelpful and misleading
> two those who want to actually implement serialization.  The items

I didn't mean to suggest that FAQ gave good advice for serialization or a 
boost serialization system should be modelled after this. I just wanted to 
highlight what I meant by "configure away the parts you don't need", and the 
FAQ answer I linked includes a list of techniques that don't support 
serialization of object graphs with class hierarchy, but still may be 
sufficient for many cases.

> really address the tradeoffs in implementing a serialization system.
> I don't think that that these items consider the power of C++
> combined with things like other boost libraries.  Anyone following
> this advice would endup writing new serialization code for every
> application - exactly the wrong direction to go.  It also also lacks
> and notion of good design - factoring data types from algorithms
> (text vs binary discussion).  Any user following this advice would
> without at least taking a hard look at the boost serialization library
> would be wasting tons of his employers money at a minimum.  It
> might even be considered by some to be a breach of professional
> ethics - unless he didn't know better in which case I suppose it would
> be excusable.

I think that FAQ is pretty old, at least part of it. it may have been good 
advice at the time, if you had to build serialization from scratch.