"Jonathan Turkanis" wrote:
// specialization for debug formatting template<> void serialize<formatted_text_oarchive>(....) {
I believe this specialization is illegal. You could write
void serialize(formatted_text_oarchive&ar, const unsigned)
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.)
Yes, this (nontemplated overloaded function) will work. I just wrote down an idea in haste.
I have two separate ideas for formatting libraries:
- one lightweight, which I posted, for input and output of ranges and tuples-like objects - one for output only, which allows much more customization; I see this as an inverse of Spirit
Your suggestion looks similar to the second (except that you want to support input), so let me sketch my idea (which has improved since I sketched it here last time), and then ask some questions about yours.
Formatted input would be optional (and maybe not practical). I do not understand what are avantages of the "lightweight" approach (except compile time). Is switch between lightweight and heavyweight solution easy? [snip]
The advantages of this approach are:
- an arbitrary amount of contextual information, such as indentation and numbering, can be stored in the styled_stream and accessed directly by formatters - arbitrary user-defined types can be formatted non-intrusively - flexible formatting is built-in for sequences and tuple-like types (and user-defined types can choose to present themselves as sequences or tuple-like types to take advantage of this feature.)
The advantages I see: - the whole infrastructure of Boost.Serialization is available and ready and it handles all situations like cycles. format_lite could concentrate on just formatting.
This is a big plus, obviously. (However, I remember Robert saying her
I feel having formatting descendant of boost::archive stream could be made with the same features. prefered
to keep formatting and serialization separate.)
Formatting, as I see it would just use Serialization as infrastructure. There would be no inpact on Serialization from Formatting.
- formatting directives can be "inherited" from "higher level of data" to "lower levels". Newly added data would not need formatting of its own by default. Change on higher level would propagate itself "down".
Can you explain how this works?
- indentation for pretty printing could be handled (semi)automatically by formatting archive.
Would this involve modifying the archive interface? I'd like a formatter for a given type (or an overloaded serialize function) to be able to access
I mean trick with RAII (its not really Serialization feature): void serialize(formatting_archive& ar, const unsigned) { // change currently used formatting style formatting_setter raii(ar, "... formattng directives...") ar & data; <<== new formatting style will be used // destructor of raii object will revert formatting back } these
properties directly.
Yes, formatting archive could have any additional interface.
- 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?
Yes, serialize() function would be specialized. I see three ways to customize output: 1. Formatting archive has its own configuration how to output data. This keeps overall style coherent and should be enough for most uses. 2. Specialization of serialize() could change formatting style. This may be used to fine tune the output here or there. 3. Specializations of serialize() may generate different outputs altogether. E.g. if you have archives: class high_level_formatting_archive {...} class all_details_formatting_archive { ... } you can omit details in void serialize(high_level_formatting_archive& ar, const unsigned); and use them all in void serialize(all_details_formatting_archive& ar, const unsigned); I think this (option 3) is not possible now with format_lite.
My experience is that Serialization is quite easy to use and lightweight enough so I do not consider it any disadvantage for practical use.
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.
I do use Serialization (with BCB). It can be put into precompiled header and this makes compilation as fast as w/o any Serialization support.
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.
I see Serialization as just vehicle, ready and handy and almost invisible to Formatting users. Simple data structures are very easy with Serialization and should be as easy as with format_lite now. If user tries to format tricky structures (e.g. pImpl) he would need to dig into Serialization docs but at least there will be chance to make the whole thing work. The Serialization goes to great lengths to work under any situation and configuration. It is also likely other Boost libs will have support for Serialization and Formatting could use it as is. /Pavel