Robert Ramey wrote:
Johan Råde wrote:
Hmmm - formatting a NaN results in something like "+inf". Personally, I wouldn't characterize that as a success.
Formatting positive infinity results in the string "inf". Parsing the string "inf" results in positive infinity. Formatting negative infinity results in the string "-inf". Parsing the string "-inf" results in negative infinity. Formatting a positive NaN results in the string "nan". Parsing the string "nan results in a positive NaN. Formatting a negative NaN results in the string "-nan". Parsing the string "-nan" results in a negative NaN. I would characterize that as success.
<snip>
This makes it difficult to implement strict_num_put. What should it do when validation fails? It can not set the failbit of the stream. The only thing it can do, is to throw an exception. The stream will catch that exception and set the badbit! At least with VC++ 7.1.
Its better than nothing. Personally I would be fine with this.
You get platform dependent behavior. VC++ 7.1 sets the badbit. Other platforms may set the failbit. (Hopefully no platform will propagate the exception.) Personally I would also be fine with that. But maybe it is not up to Boost standards.
Why? The stream probably assumes that formatting facets do not throw exceptions, so it concludes that the exception was thrown by the stream buffer. When the stream buffer is corrupted, the stream sets the badbit.
However, setting the badbit when data validation fails, is a bad idea.
How come?
The failbit should be set. Setting the badbit should mean that transporting bytes to the external device has failed.
Suggested solution: Throw out the facets strict_num_put and strict_num_get.
Comments?
You've already investigated the issue more than I have so I'm happy to defer to your judgement.
Maybe I'm too rash.
On the other hand, the attempt to serialize a NaN is an indication of a broken program I would like to see it trapable. On the other hand, it seems that I'm the only one who thinks this. Oh well.
Is serializing infinity a sign of a broken program? Is serializing a NaN a sign of a broken program? It depends on the context. (In the program I'm working on now, serializing a NaN is a sign that something is broken, while serializing infinity is not.) What is needed is maybe not different classes, but two boolean flags: trap_infinity and trap_nan. And maybe we have to accept that the exact behavior when trapping is platform dependent. There does not seem to be any way around that.
thanks for taking this on.
That is the least I can do. Your serialization library has been of immense value to me. --Johan Råde