Re:Re:Re: [boost] [serialization+date_time] Serialization

From: Jeff Garland (jeff_at_[hidden])
Date: 2004-04-25 13:34:02

On Sun, 25 Apr 2004 11:07:38 -0700, Robert Ramey wrote
> Jeff Garland wrote:
> 
> > > a) no extra compile time overhead
> > > b) no extra run-time overhead
> > > c) no extra file inclusion
> > > d) no extra "conceptual" overhead.  That is one would never have to even
> > > think about it - it would always be there just lurking waiting to be
> > > of service.  It would just work when used.
> > 
> > Are you saying there is actually extra runtime overhead with the way I've
> > implemented serialization?  If so, that needs to be in the docs b/c I was
> > under the impression that external versus internal implementations would
> > be
> > the same...
> > 
> 
> I didn't mean to imply your method had any runtime overhead - I was just
> restating all the features. However, the other points are real 
> advantages of just putting it in with the class definition.  BTW the 
> non - intrusive version could also be put in the normal class 
> header.  However if its too complicated it might end up requiring 
> more file inclusion so it would have to be considered on a case by 
> case basis.

Well ok.  Here's how I see those points:
-- a) and c) are a tradeoff.  More code to parse in when not using
serialization versus an extra header file.  That trades off against me keeping
a maintainable and flexible codebase.  I like the idea of being able to add
the serialization code indepedendently.  This also allows users to shortcut a
#include of boost/serialization altogether if they want.  I can also take
date_time out of boost without serialization if I need to more easily.
-- b) No difference as you say.
-- d) To support the no thinking part I will include the serialization stuff
in the main date_time include files.  See
http://lists.boost.org/MailArchives/boost/msg63885.php for more.

> I personally don't have a strong position on this.  As far as serialization
> is concerned the alternatives are all equivalent.  The decision 
> where to but the serialization templates can be decided on other factors.

Well, I'm not 100% sure they are equivalent.  In fact this discussion is
making me wonder if the adaptations for the standard library should be made
distinct from the serialization core to make the architecture clear. 
Something like:
  serialization/std_containers/vector.hpp
  ...

Jeff