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