Re: [boost] serialization support for date-time (wasstd::complexandboost::ublas::vector)

From: Jeff Garland (jeff_at_[hidden])
Date: 2005-08-28 13:30:07

On Sun, 28 Aug 2005 09:13:10 -0700, Robert Ramey wrote

> \>
> > Somehow I completely missed these flags when implementing the
> > date-time serialization capabilities.  Seems like the date-time
> > classes should be set to primitive_types.  But if I did this now, I'm
> > going to break existing archives -- right?
> 
> Well, the default settings are pretty good - this probably why no 
> one has ever mentioned it before.  The question is whether date-time 
> should include the class version in the seialized files.  Given the 
> non-obvious (to me anyway) nature of the implementation, it seems to 
> me that details of its serialization could be refined in the future. 
>  Recording the class verision in the archive (The default, so its 
> being done now) seems correct to me.

I expect the implementation of date-time serialization to evolve (specifically
b/c I'm considering reworking some internals and dropping support for old
compilers).  However, we thought carefully about how these types should be
serailized and no matter the internal implementation I don't expect the
serialized form will change.  So I really think the versioning is uneeded. 

Anyway, you didn't answer my question -- I presume that prior archives will be
broken if versioning is switched off? 
 
> Tracking isn't so clear.  Right now all date-time instances are 
> being tracked if its used anywhere as a pointer.  This is the 
> default.  Not really a bad choice.  But someone might say - well I'm 
> using date/time in different parts of the applications and I don't 
> want the fact that I'm serializing data/time as pointer in one part 
> of the application creating a performance bottle neck in another 
> part.  But this isn't an issue with date/time but rather an issue 
> with the concept of serialization traits in general.

I'd say it would be pretty unusual to dynamically allocate and serialize a
pointer to a date/time value.  Date/time values tend to get used as value
objects that are a part of more complex objects.  

> So I think data/time is just fine with the defaults.

Yeah, it's probably fine and will remain as is for now -- assuming my
understanding about breaking existing archives is right.  Just trying to see
if there should be future optimizations that should be applied...

Thx,

Jeff