Boost logo

Boost :

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.

>
> <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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk