From: Johan Råde (rade_at_[hidden])
Date: 2006-08-23 03:58:15
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.
>> 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
>> 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.
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk