Boost logo

Boost Users :

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


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net