On 11/9/05 11:15 PM, "Robert Ramey"
Nigel Rantor wrote:
Pragmatic:
Well, how about simply treating anything other than 1 as false? I realise this means that you are implicitly initialising someone elses variable should they serialise and then deserialise but it would seem to preserve the effect that you would witness should you use such a variable without performing that set of operations anyway so it would be an "invisible" side-effect.
Correct:
Initialise all your variables. Shoot all programmers who don't!
And of course, the one true way - tell everyone to initialise their variables or bad things might happen and then be lenient on parsing anyway.
Actually, my preferred way would be to trap the usage of an unitialized bool variable when it is saved. Its not clear that I can do this. But a close substitute might be to convert the variable to an integer, throw an exception if its not equal to 0 or 1 and serialize it otherwise.
The "Correct" method given is the only way. There's no way to detect uninitialized variables. (Anyone who took the effort to offer you a flag could have initialized the object instead.) You can't convert it to an integer, since that also requires reading an uninitialized variable. Games with "unsigned char [sizeof(bool)]" won't really work since the bit pattern(s) for each Boolean state is unspecified. As I understand it, the serialization layout of a type's components is up to the author. That means you can be selective: struct my_brokenness { bool is_next_one_valid; // if FALSE, don't set... bool the_real_value; // ...this member. int other; }; archive & operator & ( archive &a, my_brokenness &b ); { // the WRONG way a & b.is_next_one_valid & b.the_real_value & other; // the RIGHT way a & b.is_next_one_valid; if ( b.is_next_one_valid ) a & b.the_real_value; a & other; return a; } Something like this is required if a member is a "union," right? -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com