[committed] libstdc++: Add std::from_chars for floating-point types

Florian Weimer fweimer@redhat.com
Mon Aug 3 11:47:24 GMT 2020


* Jonathan Wakely:

>>What seems to be missing is a function that takes an explicit buffer
>>length.  A static reference to the C locale object would be helpful as
>>well, I assume.
>
> How expensive is it to do newlocale("C", nullptr), uselocale, and
> freelocale?

freelocale does nothing in this situation.  newlocale has a bunch of
conditional branches to detect this situation.  uselocale has fewer
branches, but has more memory accesses.

At least there's no locking involved.  (But I believe uselocale is
thread-unsafe regarding setlocale in the glibc implementation or
something like that.)

>>Maybe this is sufficiently clean that we can export this for libstdc++'s
>>use?  Without repeating the libio mess?
>
> I think we could beat strtod's performance with a handwritten
> implementation, so I don't know if it's worth adding glibc extensions
> if we would stop using them eventually anyway.

I was reminded of this query:

  Robustly parse string to unsigned integer (strtoul?)/docs
  <https://sourceware.org/pipermail/libc-help/2020-June/005337.html>

It suggests to me that we need better interfaces.

> I also noticed some strings give an underflow error with glibc's
> strtod, but are valid for the Microsoft implementation. For example,
> this one:
> https://github.com/microsoft/STL/blob/master/tests/std/tests/P0067R5_charconv/double_from_chars_test_cases.hpp#L265
>
> Without the final '1' digit glibc returns DBL_MIN, but with the final
> '1' digit (so a number larger than DBL_MIN) it underflows. Is that
> expected?

I don't know.  I think you should bring this up on libc-alpha.

Thanks,
Florian



More information about the Gcc-patches mailing list