Stefan Strasser wrote:
Am Monday 21 September 2009 20:27:59 schrieb Robert Ramey:
Stefan Strasser wrote:
I think to support this an other use cases like it common_archive would have to be moved outside of the linked library into a header and be made more generic.
common_archive is a template - it's not in the linked library.
ok, I must have mixed up some types. the point was that the ultimate base class, that handles the type registration and object tracking etc., is linked .cpp and not very configurable. the optimum case imho would be that you could pass a traits class to that archive base class, that gets called whenever there is an object or type to be registered and is queried for existing objects and types later on. that way you could disable registration, save type registration outside of the archive itself, let type registration span multiple archives etc, make sure type registration doesn't allocate etc.
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. 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. This can be seen in the class diagram for the serialization library. And your example makes me more convinced than ever that this is basically right. Now the only loose end it investigate why save/load object is required. Robert Ramey