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.
I would like to see improvements in this area. Mostly this is because I would like to see the library more "formal" and hence with less bugs, more robust, and more extensible. It's not been a huge priority since most users find the the archive classes included in the package seem addequate to their needs.
sure, it's the best serialization solution I know and the template technique trumps any reflection based solution (even if c++ had reflection). this is not meant as a critique.
such a generalization could be based e.g. on what is described as "levels of sophistication" of serialization, here: http://www.parashift.com/c%2B%2B-faq-lite/serialization.html#faq-36.2
I looked at this and found it to be very unhelpful and misleading two those who want to actually implement serialization. The items
I didn't mean to suggest that FAQ gave good advice for serialization or a boost serialization system should be modelled after this. I just wanted to highlight what I meant by "configure away the parts you don't need", and the FAQ answer I linked includes a list of techniques that don't support serialization of object graphs with class hierarchy, but still may be sufficient for many cases.
really address the tradeoffs in implementing a serialization system. I don't think that that these items consider the power of C++ combined with things like other boost libraries. Anyone following this advice would endup writing new serialization code for every application - exactly the wrong direction to go. It also also lacks and notion of good design - factoring data types from algorithms (text vs binary discussion). Any user following this advice would without at least taking a hard look at the boost serialization library would be wasting tons of his employers money at a minimum. It might even be considered by some to be a breach of professional ethics - unless he didn't know better in which case I suppose it would be excusable.
I think that FAQ is pretty old, at least part of it. it may have been good advice at the time, if you had to build serialization from scratch.