[Boost-users] Serialization: how to port binary archives containing NAN created with version 1.43 to version 1.47?

[Terry McLendive]

Hi everyone,

I am encountering a particularly gnarly version of the backward-compatibility problem with binary archives that others have discovered (here: http://groups.google.com/group/boost-list/browse_thread/thread/f4e3287f6925fc41, for example).

Specifically, I have a number of binary archives created with version 1.43 of the library that are unreadable using version 1.47. I'd like to "port" them forward, so my initial plan was to compile a simple translator program against the 1.43 library that would read the binary archives and save them as (1.43) text archives. Then, a second program compiled against the 1.47 library would read the text archives and save them as (1.47) binary. Easy peasy.

Except: the archives contain NAN values, which work fine when everything is binary but fail to deserialize for any version of the library when the archive is text (or xml, apparently), for reasons I don't quite understand.

So my question is: how can I take my (1.43) binary archives containing NAN values and get them into a format readable by the current (1.47) version of the library? Is it possible?

Thanks,

Terry

(An aside: it seems strange that I'm allowed to serialize a NAN to text, but it breaks when I try to deserialize it... why not prevent the creation of un-deserializable archives at the point of serialization?).

[Pfligersdorffer, Christian]

Hi Terry, you might want to check out our eos portable archives from:
https://github.com/boost-vault/serialization

Because of a user request we support serialization of nan and inf.
The official boost archives don't, as you already found out.

Regards,

--
Christian Pfligersdorffer
Software Engineering
www.eos.info
_______________________________________________
Boost-users mailing list
Boost...@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users

[Robert Ramey]

Pfligersdorffer, Christian wrote:
> Hi Terry, you might want to check out our eos portable archives from:
> https://github.com/boost-vault/serialization
>
> Because of a user request we support serialization of nan and inf.
> The official boost archives don't, as you already found out.

I just looked at the page. It looks very interesting to me. When
I have some time, I will be investigating which of these might
be included in the boost distribution of the serialization library.

Note that serialization of individual libraries such as tuple
bitset etc. is not part of the serialization library itself but rather
part of the particular library. (Obviously it's not scalable for
me or anyone else to implement serialization for every other
possible type.) So these should be pitched to the the maintainers
of these other packages.

Robert Ramey

>
> Regards,

[Robert Lupton the Good]

>> Because of a user request we support serialization of nan and inf.
>> The official boost archives don't, as you already found out.

> Robert Ramey wrote:
> I just looked at the page. It looks very interesting to me. When
> I have some time, I will be investigating which of these might
> be included in the boost distribution of the serialization library.

Does this mean that you plan to support IEEE special values (e.g. NaN, Inf) in boost, or some other part of Christian's work? There's traffic on the IEEE limitation (feature?) in boost::serialize dating back to at least 2005 --- some with your name on it!

R

[Robert Ramey]

Robert Lupton the Good wrote:
>>> Because of a user request we support serialization of nan and inf.
>>> The official boost archives don't, as you already found out.
>> Robert Ramey wrote:
>> I just looked at the page. It looks very interesting to me. When
>> I have some time, I will be investigating which of these might
>> be included in the boost distribution of the serialization library.
>
> Does this mean that you plan to support IEEE special values (e.g.
> NaN, Inf) in boost, or some other part of Christian's work? There's
> traffic on the IEEE limitation (feature?) in boost::serialize dating
> back to at least 2005 --- some with your name on it!
>
> R

Now I realize that the page had a number of things from different
authors. Some I've looked at before (e.g. I'm curious about YAML).

My position on the question about supporting different flavors of Nan
is the following:

a) The different flavors of NaN are not a problem in binary archives
since whatever bits a float/double data item contain are saved and
restored without checking them. Of course binary archives are not
portable.

b) For text archives, which ARE portable, this doesn't work because
the underlying text stream does not write/read NaNs in a text format.
This due only to the fact that the text archive implemenations build
upon standard streams.

c) If one want's to support serialization of different NaNs, the course
is clear: implement a derivation of standard streams which add writing
of NaN and reading thereof. Then use this extended stream as the
argument when building a text archive. This is much simpler and
more general than trying to role this functionality into the serialization
library and would have utility way beyond the serialization library
itself. I believe that code has been written and even checked in
to implement this - though it has never been reviewed as far as
I know.

Robert Ramey

[Terry McLendive]

Thanks, Christian, this looks interesting.

Do you know if they are compatible with 1.43, or if there are any special tricks I need to use to get them to work? Currently, I am able to compile with them, but I get a segmentation fault the first time I try to deserialize from a binary_iarchive (i.e., not even a portable_archive). The exact same code compiles and runs fine when I just comment out the portable_iarchive and portable_oarchive #include lines, so I'm a little puzzled as to what is going on.

Thanks,

Terry

[Pfligersdorffer, Christian]

Hi Terry, this is weird.
Could you send me a code snippet where this segmentation fault happens?

PS: The archives can be used with boost 1.33 to boost 1.47.