[boost] Re: [ANN] Format Lite

From: Robert Ramey (ramey_at_[hidden])
Date: 2004-11-12 01:35:45

"Jonathan Turkanis" <technews_at_[hidden]> wrote in message
news:cn0cmq$ja8$1_at_sea.gmane.org...

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

Hmm - I think I remember saying something like that myself.  But I can't
find it now I can't remember the exact context.  I think it was related to
some issues in implementation of certain archives and is not relevent to
Pavel's proposal.

> This is a big plus, obviously. (However, I remember Robert saying her
prefered
> to keep formatting and serialization separate.)

I do.

An Pavel's idea maintain that.  The roles of the various parts of the
serialization library are:

a) template<class Archive, class my_class> void serlialize(Archive &ar,
my_class &t) - specifiy information which is required to save and
restore(load) the state of the class T.
b) class archive - specify how data is to be stored

This means that any/all archive serializations can function wiht any
archive.  Any combination is known to be valid and function correctly.

adding Pavel's idea

c) template <> void serialize<special _archive &ar, my_class &t) - specify
special output for this combination of special_archive and my_class

This maintains the independence of serialization and archive while
permitting customization for any special combinations of archve/class
serialization.

The serialization library can be thus be used with any formatting library
(in much the same way it uses spirit to parse xml input).   Thus the is no
real conflict with the serialization library.

> > - indentation for pretty printing could be handled (semi)automatically
> >   by formatting archive.
>
> Would this involve modifying the archive interface?

all archives have the same interface.  It is never modified for particular
classes.  This a fundamental idea from which the serialization library
derives a large portion of its utility. This is why the same programs can
produce binary, text or xml_archive with no changes other than selecting a
different archive class.

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

If I understand your question correctly, the answer is yes.

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

This is most probably due the compilation of the xml_archives class which
uses spirit to parse XML input.  Not that it matters as its just a one time
cost in any case.  If fact, this is the very reason that its a library
rather than a header.

User program which use serialization library generally compile quite fast.
No one has reported that serialization adds a disproportionate amount to
compile time.  I did get one reporte from one user with 80 classes that he
was starting to get ICEs from VC 7.1 .  But that's it.

I believe that the size of library has lead some to have reservations
regarding performance of the serialization library - compile time, link
time, memory size, or execution speed - or its ease of usage.  I think that
such reservations are unfounded.  No one who has actually used the library
has voiced such reservations to me.

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

Serialization can use any formating.

A formatting library doesn't really have use for or depend upon
serialization.

However, the direction of your efforts  looks like you might be accidently
re-inventing the serialization library.  I would guess this will sort itself
out eventually.

Robert Ramey