[boost] Re: [ANN] Format Lite

From: Jonathan Turkanis (technews_at_[hidden])
Date: 2004-11-12 14:21:31

"Robert Ramey" <ramey_at_[hidden]> wrote in message
news:cn2se7$j8n$1_at_sea.gmane.org...
>
> "Jonathan Turkanis" <technews_at_[hidden]> wrote in message
> news:cn2p63$97u$1_at_sea.gmane.org...
>
> > If people like the interface (and so far there's not much evidence), I
> 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.

Thanks.

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

I'm not expecting it. But I'd still like to have a standard serialization
library, since it fills such a common neeed, and Boost.Serialization is the
definitive serialization library for C++.

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

This is what I meant by additional language support. It's a higher priority for
me than new standard libraries, because it increases the scope of what portable
libraries can do.

> > You mean no changes to the library code -- we would just define additional
> > archive concepts and types?
>
> additional archive types.

If the archives are to have additional member functions, as Pavel suggested, it
would probably be good to codify them with a new archive concept.

> > 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
> > formatting 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 this.
>
> Its not clear to me how this would be done with your proposal.

It would look something like this:

   struct Duck;
   struct Gooose;

    struct DuckStuffedWithPork
         : single_class_formatter<Duck>
    {
          template<typename StyledOstream>
          void operator()(StyledOstream& out, const Duck& d)
          { /**/ }
    };

    struct BlackenedGoose
         : single_class_formatter<Goose>
    {
          template<typename StyledOstream>
          void operator()(StyledOstream& out, const Goose& d)
          { /**/ }
    };

    struct cajun_style
        : style<
              use<Duck, DuckStuffedWithPork>,
              use<Goose, BlackenedGoose>
         >
    {  };

    styled_ostream<cajun_style> cajun_out(cout);

If DuckStuffedWithPork and BlackenedGoose weren't default constructible, I'd
have to write a cajun_style constructor sepcifying instances of these types.

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

>From what you and Pavel are saying, I'm hoping the above could be implemented
just by defining a templated archive type parameterized by a Style:

   template<typename Style, ... >
   class styled_oarchive;

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

I prefer to definine an ostream wrapper with an ostream-compatible interface.
This way you can use several different wrappers with the same ostream and
there's no possibility of passing it to a function taking an ostream& argument,
which would cause the formatting information to be lost.

> > 1. Is your idea flexible enough to allow pairs (a,b) to be formatted with
> 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?
>
> one would define a member function serialize for a specific archive class.
> This would bypass the standard templated one generally defined.

Would the member function be a member of the archive or the type to be
formatted? I'd like to be able to tell an archive to format a Duck in a
particular way whether the Duck likes it or not.

> > I wonder how much of the Serialization infrastructure is really needed,
> > though. 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 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.

Sounds good.

> > Would this really be desirable for human-readable output? Perhaps the
> > 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.

Okay, I get the picture ;-)

I have no intention of adding stuff like this to Format Lite, but I can easily
imagine it happening with the more ambitious version. So I'm inclined now
inclined to try to reuse the serialization machinery, once I see how I can be
done.

But first I'd like to get a better sense of the problems that might arise.

Regarding pointers, would you agree that most of the thorniest issues relating
to pointers disappear if you concern yourself with output only, since you
wouldn't have to detect or record the fully derived type or have a mechanism for
constructing new objects? Would cycle-detection be the only remaining issue?

Outputting arrays should be no problem. Format Lite should be able to handle
them except that I forgot to add a speciailzation of is_singe_pass_range for
arrays.

By multiple copies, do you mean multiple pointers that point to the same object?
I think an output formatting library should just output each as if the other
didn't exist.

Thanks for your help.

> Robert Ramey

Jonathan