[Sorry for the late response.]
BTW, please put in an actual subject relating your specific concern. All I
see in my e-mail client are our tags.
On 11/9/05 1:02 PM, "Paul Giaccone"
I am serialising data structures that include objects of the form:
std::vector
where MyClass contains simple times and further classes.
This would not deserialise correctly in Boost 1.33.0 when in XML format, and I think there was discussion of there being a bug in deserialisation of vectors in that version of the serialization library.
The bug persisted with the new version of Boost (not 1.33.1 that has just been released but a version from the CVS from a few days ago, which is probably close to or the same as 1.33.1 anyway).
I tracked it down to the serialisation of an uninitialised boolean, to which Visual Studio .NET 7.1 had given the garbage value 205. The serialization library generates a stream error when this is read back into a boolean, naturally enough, because it is not a valid value for a boolean.
Is this uninitialized Boolean part of Boost's serialization code, or is it part of your class (called "MyClass" here)? The person responsible for this bug is the one who owns the code at fault. Did you check if MyClass's serialization works on a single object? Did you check if serialization works on non-XML archives, both single objects and your special vector?
My question is whether the serialization library should be made more robust to handle uninitialised variables. In the case of all other variables, of course, it is not easy or not possible to detect in a simple manner whether or not a variable is initialised: is that integer meant to have value 1.23456E+66 or is it just uninitialised? For booleans, though, a value of other than 0 or 1 means it has not been initialised, and perhaps this should throw an exception on writing to the archive rather than on reading from it.
Reading an uninitialized variable that isn't an "unsigned char" (or an array of such) is undefined behavior, no matter what. Such readings can (and have on some platforms) cause a trap/crash. It is not the responsibility of the serialization routines to muddle through uninitialized variables. It's impossible anyway: 1. How is the serialization code supposed to know if the variable is uninitialized? If your code has a flag indicating whether or not the variable is initialized, just redirect your efforts into making the variable always initialized (and remove the flag)! 2. Even if detection was possible, what policy were you going to have if an uninitialized value was found? And how would you enforce it? 3. And how do you know that a "1.23456E+66" integer value is illegal value? By reading it (and causing the problems in [1])? What about values of "0" or "1" from a Boolean? You made really big and really bad assumption there; the truth is that the bit-level format of a "bool" object is COMPLETELY UNSPECIFIED! It doesn't have to use an no-set-bits pattern for False or a simple single-set-bit (or all-set-bits) pattern for True. One or both of the two valid states could have multiple bit patterns allowed. 3a. In fact, I made a shocking realization researching for this thread. The standard describes "bool" in section 3.9.1, paragraph 6. Unlike "wchar_t" (described in paragraph 5), the "bool" does not have to be a rip-off of another built-in integral type! It can a distinct integral type from "char," "short," "int," or "long." Or it doesn't have to be a true integral type at all; it could just ACT like one when focused through the compiler! (Is this realization a bug? Should I report it on "comp.std.c++"?) 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!
If handling uninitialised variables is not practical, then perhaps there could be a warning in the documentation that uninitialised booleans will cause stream errors on deserialisation.
Such handling isn't just impractical, it's impossible. It can NEVER be used as a legitimate programming technique. Why should we waste text describing any/every potential illegal program? It's also _not_ a problem specific to serialization; it's a general programming restriction that all of us should know already. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com