You guys are barking up the wrong tree. This behavior is handled by the stream implementation NOT the serialization library itself. It is exactly the same case as for floats. In this case, floats which are NaN can be written to a stream but not read back. Same for bools. There has been work in trying to make a portable implementation of stream input/output of varying types of NaN's. This has been hampered by the fact that the handling of NaN's varies accross implementation so it doesn't seem possible to make "transportable" archives which can be guarenteed to recover the same type of NaN that has been saved. For what it's worth, my personal view is that the attempt to save an undefined value - be it a NaN, undefined bool or whatever should be considered an error and trapped as soon as possible. Implementing this would be fairly easy with a custom stream facet which can be optionally attached to any stream. This would leave the choice as to what behavior he desires in the hands of the user. But no one has been motivated to actually do this so far. Robert Ramey Deane Yang wrote:
RIVASSEAU Jean Noel wrote:
I've had the same problems. The problem is with the bool field. Code restoring the archive crashes if the bool stored in the archive is not equal to 0 or 1. But since you did not write a constructor in the Obj class, the boolean will actually be initialized with anything( eg, read 14675002 for example), and will be serialized that way in the archive since it seems the serialization code does not check if the bool is equal to 0 or 1 (only the restoration code).
So, the solution is to initialize your boolean correctly and be very careful whenever you use booleans. However, I think the Serialization code should be fixed (remove the check for 0 or 1, it probably does more bad than good.
In my (very) humble opinion, it should be at least symmetric. So either no check for 0 or 1 in both directions or a check for 0 or 1 in both directions.
But it should also be consistent with other built-in types. Since it appears that there is no check (is one even possible?) for uninitialized data with other built-in types, I also vote for no check.