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

[Ruslan Kabatsayev]

Hi,

Thanks for your reply.

On Mon, 24 Jun 2019 at 22:17, Jonathan Wakely <jwakely@redhat.com> wrote:
>
> On 24/06/19 21:13 +0300, Ruslan Kabatsayev wrote:
> >Hi all,
> >
> >The C++17 functions to_chars and from_chars have been implemented for
> >integer types quite a long time. Until recently, there were no
> >implementations of their floating-point versions in major compilers.
> >Now that STL has implemented these functions completely in MSVC, I
> >wonder what their current status is in GCC.
>
> I have an implementation of from_chars for float/double/long double.
> Ed Smith-Rowland has said he's going to work on to_chars.

Thanks, this is good to know.

>
> >So, is anyone actively working on it? If not, and no one is planning
> >to begin soon, I'm considering giving it a try. But first I have some
> >questions on it:
> >
> >* What's the expected form of this functionality — should it be a
> >header-only implementation like the current one for integer types?
>
> No, definitely not.
>
> >* Could it use e.g. some dedicated functions in glibc (possibly
> >implemented specially for libstdc++ — to take advantage of the
> >existing codebase for printf), or maybe use libdouble-conversion for
> >this (it can handle float and double types, not long double though)?
>
> We can't rely on glibc because GCC supports lots of non-GNU targets.
>
> >* Does it have to be fully self-contained in libstdc++, so that no
> >external dependencies would be tolerated?
>
> Yes. Any dependencies on an external library need to be handled by
> adding the library to libstdc++.
>
> >* Does it have to noticeably outperform printf, or would basically the
> >same performance be good enough for a start?
>
> 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.

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

Thanks,
Ruslan