Re: [Boost-users] [serialization] Attaching arbitrary data to an archive

Subject: Re: [Boost-users] [serialization] Attaching arbitrary data to an archive
From: Robert Ramey (ramey_at_[hidden])
Date: 2010-06-01 16:39:04

Stefan Strasser wrote:
> Zitat von Robert Ramey <ramey_at_[hidden]>:
>

> I also overloaded the archives, but instead of getters/setters there
> is something like:
>
>   void load(type_selection &type){ ... }
>
> this decouples the info stored in the archive from the individual
> serialize() functions.
> also if the archive doesn't implement type_selection as a primitive
> its serialize() function is called, so you can react adequately when
> an archive is used that isn't subclass-ed.

as far as I can tell, this seems consistent with my original intention.
I endeavored to minimize the handling for special types.  Of course
for some specific application, I can see one wanting to add his
own special handling for types not otherwise serializable.

> robert, this seems very similar to pointer serialization to me. if a
> pointer is loaded, info stored in the archive is required (the pointer
> tracking map). same for derived type serialization.

Hmmm - sycronicity here.  1.43 includes two new case studies.  On
is for a simple light weight archive class meant to be used for debug
logging.  It only handles output, doesn't, doesn't follow derivation
paths for polymorhic base classes.  Best part is

a) it,s HEADER ONLY so it's convenient for use in debugging without
changing the build or adding another compiled library to your project.
b) it's FREE in that you've already got the serialize functions in there.
There is nothing extra to do.

But, as mentioned before, if you display a base class, that's all you'll 
get.

> maybe pointer tracking/derived types can one day be as optional as the
> shared_ptr mix-in you described is.

I'm not sure that it would be all that difficult to implement this.  The
elaborate code for handling polymorphic pointers, etc. Of course
if you don't want to repeat stuff, etc it could turn into a lot of work.

> I still use something like this just to avoid the construction
> overhead of a Boost.Serialization archive when it's not needed:
>
> class archive{
>   archive &operator<<(int t){
>     //don't need Boost.Serialization for this
>     ...
>   }
>   archive &operator<<(T *t){
>     //need Boost.Serialization for this:
>     if(!sarchive) sarchive=in_place(...
>     *sarchive << t;
>   }
> private:
>   optional<archive::binary_oarchive...> sarchive;
> }

I'm not sure I understand the motivation for this - but then I don't
have to.  Note that the implementation of the serialization library
relies on template metaprogramming to generate code ONLY
for those features actually invoked.  So, I'm not convinced of
the utility of the above approach.  Perhaps there's "too much"
overhead in the construction of an archive - but someone would
ahve to make a case for this assertion.

Robert Ramey

> Stefan