|
Boost : |
From: Reece Dunn (msclrhd_at_[hidden])
Date: 2004-09-23 13:36:29
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk