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