[serialization] strange assert with wrong cid
Hello, All! sometimes I got errors in basic_iarchive_impl::load_pointer in line assert(new_cid == cid). Can anyone tell me what exactly this assertion means and whan it can occurs? Is this error posiible if I remove some BOOST_CLASS_EXPORTs from my code and try to load old files? With best regards, Sergey
Any violation of assert is indication of a programming error (at least in the way I intend to use it). So send me some more information including boost version, compiler version, etc. If you can send a small test case that is also immensily helpful. Robert Ramey Sergey Skorniakov wrote:
Hello, All!
sometimes I got errors in basic_iarchive_impl::load_pointer in line assert(new_cid == cid). Can anyone tell me what exactly this assertion means and whan it can occurs? Is this error posiible if I remove some BOOST_CLASS_EXPORTs from my code and try to load old files?
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.
With best regards, Sergey
Hello, Robert! You wrote on Fri, 1 Jul 2005 10:04:35 -0700: RR> Any violation of assert is indication of a programming error (at least RR> in the way I intend to use it). Yes, I am understand this. But I can not understand what kind of error this assert indicates. RR> So send me some more information including boost version, compiler RR> version, etc. compiler - MS VC 7.1, boost 1.32. XML archive was used. RR> If you can send a small test case that is also immensily helpful. Unfortunately, I can't isolate problem. I had never see this error on my computer but only got reports from my colleagues, who are working at another city. ??>> sometimes I got errors in basic_iarchive_impl::load_pointer in line ??>> assert(new_cid == cid). ??>> Can anyone tell me what exactly this assertion means and whan it can ??>> occurs? Is this error posiible if I remove some BOOST_CLASS_EXPORTs ??>> from my code and try to load old files? RR> Trying to load an archive with one set of traits from a archive saved RR> with another set of traits would generally not work without making RR> special arrangements to read the "old" archives. That is, saving one RR> way and loading another way cannot be generally expected to work and RR> 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? 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. 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. With best regards, Sergey.
Sergey Skorniakov wrote:
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?
I would expect this to break any archives that contain any instances of the obsolete classes but not break any that didn't contain the obsolete classes. The question arises as to what an "obsolete class" means. How can one be sure it was never written to an archive. It had serialization in it for a reason at one time. At the very least I would be inclined to leave it with an assertion in the serialization function. Hopefully, this would trap any erroneous presumption that that an old archive doesn't contain an instance of the obsolete class. Note that handling obsolete classes through versioning can sometimes be tricky. For an example take a look at the new shared_ptr serialization which inlcludes code to handle the shared_ptr's serialized by v 1.32. The ways of doing it are totally different between the two versions. So mapping the old serialization to the new one wasn't at all straight 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.
ids are used when possible. That is when a type is automatically "registered" by its first use. Otherwise it is identified by its class 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.
well, the archive will contain a name of the obsolete class. when that name is looked up in the table which maps class names to types (extended_type_info) a matching type won't be found as the program expects and you'll get an error like class id not found - as it seems you have done. Robert Ramey
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.
participants (8)
-
Robert Ramey -
Sergey Skorniakov