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