[boost] Re: FORMAL review of "Output Formatters" - results

From: Hubert Holin (Hubert.Holin_at_[hidden])
Date: 2004-10-28 08:06:49

Somewhere in the E.U., le 28/10/2004

   Bonjour

In article <cllsnh$eb3$1_at_[hidden]>,
 "Robert Ramey" <ramey_at_[hidden]> wrote:

[SNIP problems between serialize and my current toolsets, which in the 
short term prevent me from adding serialization to quaternions and 
octonions]

> With the serialization library is intended to be used to save and restore
> the state of an arbitrary set of C++ data structures.  The particular format
> used to store the data is implemented as and "archive class".  The archive
> class can be selected independently of the data to be serialized.  Some
> archives have readable or semi-readable formats.  E.g XML or plain text,
> while others or opaque to human perception - binary.  The data stored in an
> archive is designed to capture all the information required to restore it to
> its original state and is driven by the structure of the data saved.
> Serialization is not intended for and generally not suitable for reading and
> parsing some other input format.

      OK. So while this is indeed important, it does not solve my 
problem (simplification of input operators, due to the complexity of 
legal input syntax).

> Here is where I believe the confusion lies.
> 
> a) If one wan't to display something for human consumption such as a report,
> debug log or what ever, An output format library might be useful.
> b) If one wants to save and restore something to its original state, the
> serialization libary will be useful.
> c) If one wants to read some input text in some specified format, parse it
> and generate some data instances - spirit may be helpful.

[SNIP]

> Generally, I would think that concentrating on using the above tools for the
> above purposes rather than trying to extend them too far beyound thier
> original motivation and design goals will lead to more complexity and
> overlapp than necessary or desirable.
> 
> Robert Ramey

      Precisely. But the scope of sprit is very wide, so a dedicated 
library (solving efficiently a class of problems) would be welcome. 
Nothing prevents that dedicated library being based on a more general 
framework (such as spirit, in the case of "out"put iterators), of course.

   Cordialement

         Hubert Holin