"Jonathan Turkanis" <technews@kangaroologic.com> wrote in message news:cn0cmq$ja8$1@sea.gmane.org...
but I can't say whether this will work (I seem to remember Robert saying somewhere in the documentation that he was relying on the fact that non-templates are better matches than templates.)
This is a big plus, obviously. (However, I remember Robert saying her
Hmm - I think I remember saying something like that myself. But I can't find it now I can't remember the exact context. I think it was related to some issues in implementation of certain archives and is not relevent to Pavel's proposal. prefered
to keep formatting and serialization separate.)
I do. An Pavel's idea maintain that. The roles of the various parts of the serialization library are: a) template<class Archive, class my_class> void serlialize(Archive &ar, my_class &t) - specifiy information which is required to save and restore(load) the state of the class T. b) class archive - specify how data is to be stored This means that any/all archive serializations can function wiht any archive. Any combination is known to be valid and function correctly. adding Pavel's idea c) template <> void serialize<special _archive &ar, my_class &t) - specify special output for this combination of special_archive and my_class This maintains the independence of serialization and archive while permitting customization for any special combinations of archve/class serialization. The serialization library can be thus be used with any formatting library (in much the same way it uses spirit to parse xml input). Thus the is no real conflict with the serialization library.
- indentation for pretty printing could be handled (semi)automatically by formatting archive.
Would this involve modifying the archive interface?
all archives have the same interface. It is never modified for particular classes. This a fundamental idea from which the serialization library derives a large portion of its utility. This is why the same programs can produce binary, text or xml_archive with no changes other than selecting a different archive class.
- multiple formatting styles could be provided for any class.
It would be one formatting style for each archive type for which serialize has been specialized, correct? Would this allow styles for various types to be mixed freely?
If I understand your question correctly, the answer is yes.
I've read the Serialization documentation, but haven't used it yet. I've noticed it takes a long time to build, but this is probably because of the various combinations of threading, debugging and linking options.
This is most probably due the compilation of the xml_archives class which uses spirit to parse XML input. Not that it matters as its just a one time cost in any case. If fact, this is the very reason that its a library rather than a header. User program which use serialization library generally compile quite fast. No one has reported that serialization adds a disproportionate amount to compile time. I did get one reporte from one user with 80 classes that he was starting to get ICEs from VC 7.1 . But that's it. I believe that the size of library has lead some to have reservations regarding performance of the serialization library - compile time, link time, memory size, or execution speed - or its ease of usage. I think that such reservations are unfounded. No one who has actually used the library has voiced such reservations to me.
My inclination is to keep formatting separate from serialization, though, because they have different aims. If you believe they can be integrated, without making serialization harder to learn or sacrifying flexibility of formatting options, it should definitely be considered.
Serialization can use any formating. A formatting library doesn't really have use for or depend upon serialization. However, the direction of your efforts looks like you might be accidently re-inventing the serialization library. I would guess this will sort itself out eventually. Robert Ramey