$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
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