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

From: Robert Ramey (ramey_at_[hidden])
Date: 2005-08-28 11:13:10

Subsequent to this I studied a little bit more.  I suggested that the 
std::complex type be marked as object_serializable.  This means that the 
serialization functions are called but class verision information is not 
stored in the archive.  This might be faster/more efficient then the 
default, but creates a problem if the serialization of the item is changed 
in the future.  Given the simple nature of std::complex, I don't anticipate 
that happening.

primitive would mean that the serialization functions aren't called at all 
and the archive handles them within the archive code.

I also suggested that std::complex be untracked.  That's because I see this 
as a type widely used accross different application areas. So it seems to me 
that this is correct.

\>
> 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.

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.

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

Robert Ramey