Re: [Boost-users] [serialization]

From: Robert Ramey (ramey_at_[hidden])
Date: 2005-11-13 13:26:49

Daryle Walker wrote:
> In this case, we would have a bug in the decoding and encoding
> routines. The bug would be that they don't match.  If the coding
> routines are calling the standard library (like I think they are for
> text archives of primitive types), then the bug is from the standard
> library not being symmetric.  I think the standard library is
> supposed to give symmetric text I/O

I don't know what the standard library is supposed to do.  But
the fact is that at least some implementations of he standard
library are not handling text i/o symetically in at least two cases:

uninitialized bools.
floating/double NaN, +/- inf, etc.

> so how much effort should we do
> to work around such bugs?

actually, the effort for uninitialized bool is pretty trivial and I've
incorporated and assertion into the appropriate spot.

For the others, its a little more work.  If someone has enough
interest to actually make and test the changes, I'll be happy to
receive them, check them, and incorporate them in to the code.
I would expect that only some small changes in ??text_i/oprimitive
would be necessary.  Oh it would be a bad idea to post them to
the list.  Personally, I'm of the view trying to serialize a NaN would
probably a be bug in user code.  I'm aware that not everyone
would agree with this.  Maybe throwing an exception might
be enabled/dissabled with another flag applied at archive open
time (like no_header, etc).  Any way, its not a big issue for me.
Presumably, if someone has interest he can submit his
improvements and we can discuss it then.

> Reading from an uninitialized variable, like what could happen in the
> original case during encoding, is not a problem any library can fix.
> The programmer just has to be non-sloppy.

lol - and further more, if we catch him doing something like this
we should make sure we don't tell him so he get his deserved
punishment!!!!

>> I think in the case reported by Paul, he's not necessarily using the
>> unitialised value, as its an object that is kind of like a
>> discriminated union. I think this usage parallels the idea of NaN's
>> etc in floating point. I'd expect these to be read back in too, as
>> you suggested.
>
> The problems are not in parallel.  For a discriminated union, it is
> the responsibility of the coding author to determine which fields are
> active and only read/write those particular fields and skip the
> inactive fields.  The unusability of NaN values is from a high-level
> perspective, such values are still valid objects from a low-level
> view.  (And the high-level view is just an opinion; some programmers
> might want to keep NaNs around as a flag.)

This articulates my view.  I used the term "overloading" as
in semantic overloading where we might use NaN to mean something
specific.  I can see where this might be useful in some narrow contexts
but I would generally consider it an error prone practice.  Just
one man's opinion.

Robert Ramey