[boost] Re: [ANN] Format Lite

From: Pavel Vozenilek (pavel_vozenilek_at_[hidden])
Date: 2004-11-11 16:19:01

"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.)
>
I feel having formatting descendant of boost::archive stream
could be made with the same features.

> > 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
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?
>
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
}

> > - 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
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