On 11/14/05 7:59 AM, "Kevin Wheatley"
Daryle Walker wrote:
4. If you're using some sort of (discrimated) union, where only some of the members are valid at any time, then you must serialize only the currently active ones. It is IRRESPONSIBLE for you to do otherwise!
As I wrote that particular bit, I'll take the heat for it ... its not really a discriminated union, I used that as a loose desciption for what is actually occuring, So that's not Paul's fault :-)
I think the only thing that everybody agrees on here is uninitialised variables are bad...
Yes, reading them is bad. But advice applies even outside of unions. If the object will always be used then always initialize it. If it's only used sometimes, then you need a flag indicating its activity and skip using that object when it's inactive (or initialize and activate it).
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?
It chooses to write a bool in the form of "0" or "1", so if it writes "205" (the value we actually found when we inspected our text archive) we could see it wasn't a valid value and quickly fixed our code's problem, it would have been nicer, in this case, if could have spotted that the archive althought appearing to have been written without error, was in fact 'corrupt'. My approach to this would be a data paranoia mode which verifies the conversion will convert back on loading that doesn't trigger an assert, but throws an exception, but clearly thats more work than an assert in this case.
Which ever way we no longer have the problem
Not if you just quick-patched the symptom and not the cause. You could have just turned your 100% bug into a Schroedinbug or Heisenbug. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com