Re: [Serialization] archive_exception from bad interaction serialization() and load_construct_data()

From: Boylan, Ross (Ross.Boylan_at_[hidden])
Date: 2021-06-14 19:13:55

I wrote
------------------------------------------ 
Sent: Thursday, June 10, 2021 5:17 PM

In short, combining a class implementation of serialize() with load/save_construct_data as described in the docs writes and reads data twice.
Varying the pattern can produce exceptions.  My solution is to implement serialize() as a no-op and provide paired load/save_construct_data() functions.  Is that actually a solution?  Is there a better way?
.....
-----------------------------------------------

At least for the real problem, the "solution" did not work.
First, I got errors about unknown types until I added a call to
boost::serialization::base_object<MyBaseClass>(*this)
in the otherwise empty method of the derived class.  I tried other approaches to registering the relationship, but none worked.

Second, even having done that I was unable to read in the serialized data.  The problem is that the output file has more stuff in it than the input serialization expects.  Here's the start, with offset on the far left, followed by hexadecimal representation and then plain text:
00000000: 3232 2073 6572 6961 6c69 7a61 7469 6f6e  22 serialization
00000010: 3a3a 6172 6368 6976 6520 3139 2030 2031  ::archive 19 0 1
00000020: 2030 0d0a 3020 3020 3020 3137 2043 003a   0..0 0 0 17 C.:
The 17 at the end is a character count, with C: the start of the string using multibyte encoding.
On input, the code starts looking for the character count several positions before the 17,
ending up with a 0 count and sequencing problems that soon lead to an exception.

The reading and writing code appears completely symmetric: the load and save_construct_data methods match; the serialization code is the same in both directions; both do register_type<MyDerivedClass>() on the archive just after creating the archive object and just before serialization; both execute the load/save_construct_data code before the class-based serialization code.

My suspicion is that the "extra" stuff relates to the derived and base classes, although the register_type function didn't seem to generate I/O on output or input.  

After several days of debugging and experimenting I decided not to use the serialize library, at least with objects lacking a default constructor.

Ross