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

From: Hubert Holin (Hubert.Holin_at_[hidden])
Date: 2004-10-26 07:23:06

somewhere in the E.U., le 26/10/2004
  
   Bonjour

In article <cljp56$68k$1_at_[hidden]>,
 "Robert Ramey" <ramey_at_[hidden]> wrote:

> "Hubert Holin" <Hubert.Holin_at_[hidden]> wrote in message
> news:Hubert.Holin-89E7B0.14253525102004_at_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