If people like the interface (and so far there's not much evidence), I
"Jonathan Turkanis" <technews@kangaroologic.com> wrote in message news:cn2p63$97u$1@sea.gmane.org... think
Format Lite would stand a reasonable chance of making it into TR2.
For what its worth, I like the interface. I much appreciate a small library whose usage can be completely described in a couple of pages of documentation. I could easily imagine someone using this to implement a custom archive in the serialization system.
To get Serialization standardized would require a much bigger push, IMO, although I'd like to see it happen -- perhaps with additional language support.
I would never expect such a think to happen for a number of reasons. However, it could occur that the standards (compiler and library) might be enhanced to better support serialization. This includes things like better support for type traits, reflection, guid assignment and export, options to override/require code inclusion. It might also impose requirements the libraries expose enough information to permit serialization. All these issues created difficulties in making the serialization library.
You mean no changes to the library code -- we would just define additional archive concepts and types?
What I meant to ask can be illustrated by an example. Suppose you have two classes, Duck and Goose. Duck and Goose each have two associated
styles. The choice of styles should be independent, so we would need four archive types to handle the various combinations.
Now my question is: would Duck need four specializations of serialize, or just two? In my system, formatting options for Duck and Goose could be added to a Style independently; I want to know if overloading serialize can handle
1. Is your idea flexible enough to allow pairs (a,b) to be formatted with
additional archive types. formatting this. Its not clear to me how this would be done with your proposal. Would you condition code depending on? A macro, commenting out code, some execution time switch?. Whatever method you use to implement this idea with the formating library would carry over to the implementation of the same idea with the serialization library. What Pavel's idea does is to introduce the idea of an archive format selector which would choose between different desired formats. Of course the formt library could easily do the same thing by defining derivations from output streams and implementing different versions of operator<< for each one. The usage would be identical. the
elements in reverse order?
very much so
2. If a type defines a member function serialize, can it be bypassed altogether in favor of an end-user supplied formatting style?
I wonder how much of the Serialization infrastructure is really needed,
Detecting cycles is definitely not something I want to reimplement; OTOH, I'm not sure it's needed for pretty-printing. I haven't looked at the Serialization implementation, but I did read the Java serialization specification several years ago. IIRC, when an object was encountered for the second time, some sort of placeholder would be inserted in the stream referencing the already serialized data. I assume the Serialization library does something like
Would this really be desirable for human-readable output? Perhaps the
one would define a member function serialize for a specific archive class. This would bypass the standard templated one generally defined. though. this. That is correct. However, the behavior can be suppressed with class serialization triaits. In the next version there will exist the ability to suppress this and a couple of other facilities on a archve by archive basis. This will be implemented to make the serialization library more useful for such things as transaction rollback/recovery and debug logging. formatting
library should concern itself only with cycle-free data structures.
Your library is very attractive and easy to use. I can imagine that people will find it attractive and start to use it. Then you start to get requests like, can I use it for pointers?, what about multiple copies, what about built in support for arrays, etc on and on and on. The your very readable document starts to get cluttered up with special cases (e.g. cycles, pointers, etc), and your code starts to get complicated with code to detect violations (e.g. detecting cycles, etc). You really can't get the monkey off your back until you end up covering just about everything. oh - but then its not simple anymore and you have to go back and try to re-rationalize it. The point is that the serialization library has already been through that mill - and more or less emerged intact. Robert Ramey