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