Re: [Boost-users] Ann: Floating Point Utilities Review starts today

From: Robert Ramey (ramey_at_[hidden])
Date: 2008-02-18 13:18:12

Johan Råde wrote:
> John Maddock wrote:
>
>> 3) C++ locale facets: these will read and write non-finite numbers
>> in a portable and round-trippable way: that is not otherwise
>> possible with current C++ std library implementations.  These are
>> particularly useful for number-serialisation for example.
>>
>> Since the design is already specified by the C++ standard for these
>> facets, your review here should focus on implementation, testing,
>> documentation, and perhaps where in Boost these should best be
>> placed if accepted.
>
> Actually, there are som interface issues to be discussed here:
>
> 1. Are the trap_infinity and trap_nan flags a good idea?
> I added them at Robert Ramey's request, but I'm not convinced myself.
> The implementation is not entirely satisfactory.
> In the ideal implementation both nonfinite_num_put and
> nonfinite_num_get would report infinity or nan by setting the failbit
> of the stream.
> The problem is that the std::num_put facet don't have access to the
> stream state.
> Hence std::num_get reports infinity or nan by setting the failbit of
> the stream
> while std::num_put reports infinity or nan by throwing an exception.

Hmm - I don't remember requesting this - of course that doesn't mean
I didn't do it.  I do believe that portable FP classification is necessary
but I don't think it has to be an exception.  I think one would expect
the following behavior in a serialization library.

a) option to request trap on attempt to serialize NaN.  This would be
implemented as part of the serialization library.
b) permit portable serialization of NaNs.  Implementing this
would require the ability to class the the FP objects on saving
and "re-create" the same type of objects when loaded.  Its not
clear to me that this is even possible when moving text versions
of archives across architectures since not all architectures support
all types NaNs.

The problem came up in the context of serialization library usage
but of course its really an issue with stream IO as it relates to NaNs

Robert Ramey

> 2. I have chosen to implement the flags as arguments to the
> constructor.
> The flags can not be changed after the facet has been constructed.
> An alternative design would be to use the xalloc and iword mechanism.
> Then one could have an interface for changing the flags using stream
> manipulators.
> But that would require a cpp file to be added to the library.
> (I consider this a flaw in the design of the standard iostreams
> library.
> A design that relied on GUIDs instead of xalloc would be more
> flexible.)
>
> 3. nan is formatted as "nan" or "-nan" depending on the signbit.
> Maybe the default should be to always format nan as "nan",
> and have a signed_nan flag, similar to the signed_zero flag,
> to show the signbit when formatting nan.
>
> --Johan