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

Stefan Strasser wrote:

Zitat von Robert Ramey :

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: optionalarchive::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