somewhere in the E.U., le 26/10/2004 Bonjour In article <cljp56$68k$1@sea.gmane.org>, "Robert Ramey" <ramey@rrsd.com> wrote:
"Hubert Holin" <Hubert.Holin@meteo.fr> wrote in message news:Hubert.Holin-89E7B0.14253525102004@sea.gmane.org...
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, 4.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 legal inputs.
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 flexible) wart.
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
Merci Hubert Holin