[boost] Re: [ANN] Format Lite

From: Robert Ramey (ramey_at_[hidden])
Date: 2004-11-12 12:38:16

"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.   I could easily imagine someone using this to implement a
custom archive in the serialization system.

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

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

additional archive types.

> 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.  Would you
condition code depending on? A macro, commenting out code, some execution
time switch?.  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.

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.

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

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

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

Robert Ramey