Hello, Robert! You wrote on Mon, 4 Jul 2005 08:59:22 -0700: Thanks, Robert. Your overwiew of versioning should help me to clean up what going wrong. ??>>> Trying to load an archive with one set of traits from a archive saved ??>>> with another set of traits would generally not work without making ??>>> special arrangements to read the "old" archives. That is, saving one ??>>> way and loading another way cannot be generally expected to work and ??>>> should give an exception. ??>> ??>> Ok, we are using class versioning to support loading of older ??>> versions of classes. Can we remove obsolete classes (serialized by ??>> pointer to base) from time to time or this will break reading ??>> archives even if no instances of such classes was used during ??>> writing? RR> I would expect this to break any archives that contain any instances of RR> the obsolete classes but not break any that didn't contain the obsolete RR> classes. The question arises as to what an "obsolete class" means. How RR> can one be sure it was never written to an archive. It had RR> serialization in it for a reason at one time. At the very least I RR> would be inclined to leave it with an assertion in the serialization RR> function. Hopefully, this would trap any erroneous presumption that RR> that an old archive doesn't contain an instance of the obsolete class. RR> Note that handling obsolete classes through versioning can sometimes be RR> tricky. For an example take a look at the new shared_ptr serialization RR> which inlcludes code to handle the shared_ptr's serialized by v 1.32. RR> The ways of doing it are totally different between the two versions. RR> So mapping the old serialization to the new one wasn't at all straight RR> forward. ??>> I see some class names and numeric ids for classes in ??>> archives but I'm not sure that these names or ids used for ??>> polymorphic loading. RR> ids are used when possible. That is when a type is automatically RR> "registered" by its first use. Otherwise it is identified by its class RR> name declared with export. ??>> Of course, if ids used, we should not remove any ??>> class that marked with BOOST_CLASS_EXPORT macro, but if class names ??>> used, I see no reasons why we can't drop obsolete classes. RR> well, the archive will contain a name of the obsolete class. when that RR> name is looked up in the table which maps class names to types RR> (extended_type_info) a matching type won't be found as the program RR> expects and you'll get an error like class id not found - as it seems RR> you have done. With best regards, Sergey.