Zitat von Robert Ramey :

Noah Roberts wrote:

...

Sometimes during serialization an object needs to know a lot more than it does during normal operation. The way I've dealt with this in the past is to subclass the archive I want to use and add setter/getters for the data that various objects down the line are going to need to store and retrieve themselves.

Is there a better way though, something that's built into the library already maybe? I don't see anything but I thought I'd ask.

my solution is pretty similar, but I think somewhat cleaner at least in my case, because the serialization can depend on the kind of archive that is used: instead of the serialize() functions extracting the additional data they need from the archive, I introduced a new serialization primitive. in my case, the serialize() function needed to serialize a type, one out of many, so on load() it needed to know what types to consider -> stored in the archive. 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. 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. maybe pointer tracking/derived types can one day be as optional as the shared_ptr mix-in you described is. 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; } Stefan

Zitat von Robert Ramey :

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

I'll have a look, thank you.

...

I still use something like this just to avoid the construction overhead of a Boost.Serialization archive when it's not needed

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.

in libraries under construction STLdb, Persistent and maybe even STM we (ab)use serialization for copying, cloning, comparing,... individual objects. so in a lot of cases an archive is constructed, used to serialize exactly ONE object and then destructed, because archives cannot be reused as their state cannot be reset. (and even if their state could be reset, there would be thread-safety issues.) consider for example: /// creates a deep copy of t template<class T> T copy(T const &t){ { memory_oarchive ar; ar << t; } T tmp; { memory_iarchive ar; ar >> tmp; } return tmp; } "clone" instantiated with a very simple type that doesn't serialize pointers results in almost no code, almost as if operator= was used in case a deep copy doesn`t differ from a shallow copy for that type. almost any archive construction overhead is "too much" overhead here. Stefan