Re: [Boost-users] [serialization]

From: Daryle Walker (darylew_at_[hidden])
Date: 2005-11-13 09:35:41

On 11/11/05 5:12 AM, "Kevin Wheatley" <hxpro_at_[hidden]> wrote:

> Ian McCulloch wrote:
>> I don't really have an opinion here, but why is it the job of the
>> serialization library to attempt to detect completely unrelated programmer
>> errors?
> 
> My concern is that the library can write out something it cannot read
> back in... this conflicts with its most obvious use, taking an object,
> writing it to disc, reading it back in, exactly as it was before
> writing to disc (assuming same machine reading writing, ignoring
> memory locations for pointers etc).

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, so how
much effort should we do to work around such bugs?

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.

> 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.)

> However, having a debug flag separate from NDEBUG, that puts in
> stricter checks at the expense of speed of serialisation is a good
> idea IMO. This should be orthoganal to the serialisation of a
> bool/float/whatever.

-- 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT hotmail DOT com