From: Hubert Holin (Hubert.Holin_at_[hidden])
Date: 2004-10-26 07:23:06
somewhere in the E.U., le 26/10/2004
In article <cljp56$68k$1_at_[hidden]>,
"Robert Ramey" <ramey_at_[hidden]> wrote:
> "Hubert Holin" <Hubert.Holin_at_[hidden]> wrote in message
> > It is not immediately clear if [serialize] can do that in any way
> > which is simpler to implement than what I already do for these classes
> > (i.e. it would likely be as disgusting and unmaintainable, however
> > necessary).
> I don't think there is any factual support for that statement.
My claim simply is that I can't see how to do it, not that nobody
can do it :-) !
> As a counter example, The following code includes implementation of
> serialization for the quaternion class template (17 lines of code) and a
I could not get your code to compile (either using MWCWPro8.x or
Xcode 1.5), so I could not test it. From what I understand (I may be
wrong, of course), the output should works more or less like the
non-fancy one already in place. However, its the input that's the core
of the problem.
Granted, you code will most likely read a quaternion which would
be in a text file in the form (excluding the quotes written here for
clarity) "(1.0, 2.0, 3.0, 4.0)". But will it also accept "1.0", "(2.0,
3.0)" and "((1.0, 2.0), (3.0, 4.0))" while refusing "((1.0, 2.0), 3.0,
> test of its serialization. I only spent an hour on it ( most of which was
> perusing the quaternion docs and code so it might benefit from more effort
> and testing than I am in a position to invest. But I would hope that it
> does illustrate how easy it is to serialize what might seem to be an
> otherwise complex type. I would hope it also will help to refute the
It is not the type which is complicated here, it is the format of
> perception that the serialization library is "too big". I don't believe
I will not comment on that, as I have frankly no idea about it. If
a library is useful, I will use it, no matter how big (I do not do
embedded :-) ). The only problem with "big" libraries is that they are
more difficult to maintain, and thus more error-prone. They may also
prove to be more difficult to port.
> that serialization adds any more code (source and/or object) to an project
> than any comparable alternative method.
> For example, the i/o code built into the the quaternion class contains 329
That's why I really want to improve on that, even at the cost of
an additional dependency. The octonion library is far, far, worse...
> lines of templated code. And, it doesn't include any facilities that come
> for free with serialization libary such as the ability to create archives of
> different types included XML, binary etc. It is also pure template code
True. I am not against serialization for quaternions and octonions
(heck, if anybody wants it, and it can be done in a way which will not
preclude a simplification of the input operator whilst maintaining its
current flexibility, I'll add it after the Boost 1.32 release!), it is
just I do not see how it can simplify the horrible (but remarkably
> that doesn't factor out commonality into a separart module so I would expect
> to to be more "too big" than the equivalent of the serializaition library.
> Robert Ramey
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk