Re: [Boost-users] [serialization]

Daryle Walker wrote:

On 11/14/05 7:59 AM, "Kevin Wheatley" wrote:

...

I'm more interested in knowing I could do the following...

lets say I archive an object using binary archives ... everything goes back and forth no problems, switching to text archives I'd expect the same behaviour more or less, so ideally if the value of my unitialised int happens to be 42, then when I get it back it should still be 42 when its read back in, this is fine, but if the value goes outside of the range say when its not an int but a bool, then we have a problem. The simple 1 line assert appears to detect the condition that occurs on read back, which is that the serialization library cannot read back things it *successfully wrote* as far as the calling code is able to detect.

It was NEVER successfully written, since the object was never initialized when it was read. Undefined behavior means that anything could happen. The fact that you can "get away with it" with some combinations of input does not excuse the programming technique. Your difference between input and output shows that you didn't even get away with it. (And using an "int" isn't safe; any type besides "unsigned char" may have illegitimate bit patterns that could trap.) Are you just practicing, or is there a reason why you can't apply my "initialize or skip" advice?

Daryle, you seem to be missing the point... Kevin and I have long since fixed this bug and have no interest in serialising uninitialised variables. All that is required is a note in the docs under "stream error" saying that one thing that can cause this exception is an uninitialised variable, which allows the user to go and fix the problem quickly. No user in their right mind would want to serialise uninitialised variables (leaving aside quiet NaNs). *Nothing more is required.* Paul