Hartmut Kaiser wrote:
Jonathan Turkanis wrote:
I see the library as the inverse of Spirit. Spirit takes a linear text and builds complex objects, while the output formatting library takes complex objects and renders them as linear text. Just as an abstract syntax tree does not preserve all the information in the input text, in many cases it will be desirable to loose information when an object is formatted using the present library. For example, sometime you might want a dog to be formatted as follows
This is an interesting idea. Boost.Spirit is designed to take a sequence (a pair of forward iterators stored in a "scanner") of data (characters or tokens) and apply a set of rules on that data. Boost.Spirit is also able to behave contextually depending on what the next element(s) are in the data sequence. The Serialization library provides a way to save an object to a device at run-time and load it back at some point in the future, allowing it to be stored in a binary, text or XML format. The data written to the storage is not designed to be read by a human. My library is aimed at this market: producing human-readable output to a standard stream. This is most useful in debugging and tracing, but has applications elsewhere. Roland has given an example that uses lexical_cast: // initialize a std::list container: std::list< int > l = lexical_cast< int >( "[ 1, 2, 3 ]" ); For this to work, input facilities in my library is essential. NOTE: There is an issue with lexical_cast turning off whitespace skipping, but it should be trivial for my library to set and restore this flag during a read operation.
I 100% agree with that. Moreover I have a first experimental implementation of such a library here, which is able to do formatted output controlled by a structure, which is very much similar to the Spirit grammar DSL. BTW, the name of this library is Tirips (reversed Spirit) :-).
[snip]
I'm currently at the early stages of such a library so there isn't very much code to show, but if anybody is interested I'm happy to collaborate on discussing and implementing this.
Maybe it would be a good idea to have several competing proposals. We could then see how they compare when generating certain output formats on different types of data. Maybe Gennadiy could implement his proposal so it can be compared as well. Thoughts? Regards, Reece