Boost logo

Boost :

Subject: Re: [boost] Boost XML Serialization Stability across library versions
From: Robert Ramey (ramey_at_[hidden])
Date: 2017-01-25 01:01:13


On 1/24/17 6:29 PM, Adlai Shawareb wrote:
> Thank you. We are really looking at Boost Serialization as a way to manage changes in the data stored in the memory chip. In future versions we may add a float or remove an int, and need to be backward compatible with those changes.
>
> Is there a feature in Boost that would support managing data in that way?
>
> The only alternative to serialization we've come up with is to use unions and structs to selectively include or exclude data as the versions change.
>
> Thanks,
> Adlai

I think you're confusing two different questions

a) The library maintains backward compatibility to your previous data.
So if your data changes, you can still retrieve data from older
archives. This is referred to as "versioning".

b) The same system is applied to maintaining backward compatibility to
structs from the standard library, - vector, optional, etc....

c) some structures from the standard library don't have a version number
encoded in the data. versioning is maintained by a library version
number encoded in the header record.

d) This also maintains backward compatibility when you change your
compiler to another version.

e) This is all described in the documenation along with examples.

f) This has worked well. In a couple of very rare instances it has
occurred this this versioning between libraries has been messed up for
one or another data type. I regret this. I would like to see an
expanded test suite to address this and hence be able to guarantee that
this problem would never occur. Unfortunately, no one has expressed the
view that this is sufficiently necessary in order to justify the
expenditure required.

g) In your case, I would recommend creating some tests of your own that
you could run on every new version of the library so that you would
absolutly that backward compatibility has not been broken.

I thought you were referring to abi compatibility - which I don't
believe can be guaranteed. But now I see this is not your question.

Robert Ramey

>
> From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of Robert Ramey
> Sent: Tuesday, January 24, 2017 5:54 PM
> To: boost_at_[hidden]
> Subject: Re: [boost] Boost XML Serialization Stability across library versions
>
> On 1/24/17 3:52 PM, Adlai Shawareb wrote:
>> Hi,
>>
>> We want to generate an Serialized XML archive now, and be able to deserialize it and get the same data it in the future.
>>
>> Is Boost XML Serialization guaranteed to be compatible across versions of the library?
>
> It is certainly meant to be. But it is not explicity tested so it can't
> be guaranteed. If someone wanted to make tests for this, we would look
> into incorporating them into the test suite.
>
>>
>> The XML serialized archive would be stored in a memory chip and, in the future, read back and deserialized. I don't believe that would impact the answer, but want to offer that.
>
> Hmmmm. Remember that the XML generated by the serialization library
> includes special tags to support the recover of the original C++ data
> structure which produced the archive. So it's not particularly well
> suited to "external" applications and, as far as I know, used to recover
> the data by a C++ program. So if one is going to do this, I don't see
> much point in using xml. One could get the same portability while using
> plain text with a lot less overhead.
>
> Robert Ramey
>
>> Adlai
>>
>> _______________________________________________
>> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>>
>
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>
> ________________________________
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk