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