What's the status of to_chars/from_chars for floating-point types?

[Jonathan Wakely]

On 25/06/19 15:01 +0300, Ruslan Kabatsayev wrote:
>> If it doesn't outperform printf then it might as well just be
>> implemented by calling printf. So I think a non-trivial implementation
>> that fails to outperform printf is a waste of time.
>
>Actually no, the "shortest representation" requirement can't be
>satisfied using only printf (it takes number of digits as input
>parameter), some logic must be implemented to find out the number of
>digits for each particular value. Though maybe that's what you meant
>by trivial — calculate number of digits and call sprintf.

Yes, that's true, printf alone isn't a valid implementation.

>>
>> The state of the art is https://github.com/ulfjack/ryu which also
>> needs a complete implementation of Dragon4 or Grisu3 for some edge
>> cases. And if I understand correctly, it doesn't support long double
>> (and GCC supports multiple different formats for long double,
>> depending on the target).
>
>Thanks for this, didn't know of this algorithm. From what I read in
>the paper, Ryū doesn't need the fallbacks to a slower implementation —
>it's only Grisu3 who does. And regarding long double, the GitHub repo
>you link to does have 128-bit API and explicit support for 80-bit
>(exp15/mant63) floats (see issue #13 there).

Ah, maybe my information is out of date.

12 months ago Ryu only supported scientific format, so for fixed
format you needed something else. Ryu also couldn't handle outputting
a specified precision, it always stopped at the shortest
representation. And it didn't support hex output.

Maybe that has all been added now, along with support for >64-bit
types.