Re:Re: [boost] [serialization+date_time] Serialization Review:serialization of dates

From: Jeff Garland (jeff_at_[hidden])
Date: 2004-04-25 11:48:44

On Sun, 25 Apr 2004 09:11:28 -0700, Robert Ramey wrote
> Jeff Garland wrote:
> 
> >Well, I think it belongs in the library supplying the data type not in
> > serialization.  Few reasons for this...
> 
> ... good reasons listed
> 
> 4) Many serialization implementations will turn out to be trivial. 
>  An example is Thorsten O? pointer container wrapper class which 
> resulted in 6 lines of code.  Furthermore these six lines were 
> inline template member functions (two functions 3 lines each) which 
> required no header inclusion at all.  In cases such as this, the 
> compiler/runtime cost is zero if the application doesn't use 
> serialization.  I believe that this will be a common case for many 
> of the "utility" classes.

Agreed.

> FWIW - this gets my vote:
> 
> > So for the particular case I posted I was planning on putting this code in
> >  boost/date_time/gregorian/greg_serialize.hpp
> 
> > Time could would go into 
> > boost/date_time/posix_time/time_serialize.hpp
> 
> Considering the above, you might want to think about tweaking date 
> time.  

Sure, I might.  Of course date is only one of several things I need to add
serialization to.

> By making a default constructor (that initializes as "not a 
> date"), 

Don't get me started on this ;-)

> you could implement serialization as template member 
> functions along the lines of the above.  In this way adding 
> serialization would:
> 
> 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... 

Jeff