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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk