Am Monday 21 September 2009 21:25:28 schrieb Robert Ramey:
as I alluded to before - what I would like to know is why I derived trivial_archive from common_archive. I don't remember what made me do this. It seems that if this isn't done then save/load_object is necessary. So the question is - why is this? It is an oversight somewhere? or does the archive concept have to be changed.
common_?archive derives from basic_?archive, which implements the save_object/save_pointer functions: type registration and object tracking. so if you need to serialize graphs (as opposed to trees) you have to derive from basic_?archive, unless you want to implement your own registration system.
Personally, I generally don't like the "traits class" as an argument. It sort of implies that that the template has a lot of "if -" code which navigates the traits. A "policy class" is better but can still make things complex. Personally I prefer composition of funtionality through inheritance.
I'm not sure if we talk about the same thing when we say "traits class". it does accomplish composition of functionality, just not through inheritance. see http://www.boost.org/doc/libs/1_38_0/doc/html/intrusive/node_algorithms.html... for an example from boost.intrusive. the traits class isn't a configuration class, requiring if-then-else code in the archive class, but provides actual functionality - type registration and object tracking. so it would have functions like register_object, get_object, etc. the default argument to the traits template parameter would implement the current type registration and object tracknig system, using the STL maps that have caused trouble for some of us. maybe that could also be inserted somewhere in the inheritance tree and a traits class be avoided if you prefer that. the goal in any case is to be able to store that object tracking/type registration information somewhere other than STL containers that are hardcoded in the archive base class, without having to reimplement serialization logic.