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

Jonathan Wakely jwakely@redhat.com
Tue Jul 28 21:02:24 GMT 2020


On 28/07/20 22:01 +0100, Jonathan Wakely wrote:
>On 27/07/20 10:46 +0100, Jonathan Wakely wrote:
>>On 27/07/20 11:41 +0200, Rainer Orth wrote:
>>>Hi Jonathan,
>>>
>>>>This adds the missing std::from_chars overloads for floating-point
>>>>types, as required for C++17 conformance.
>>>>
>>>>The implementation is a hack and not intended to be used in the long
>>>>term. Rather than parsing the string directly, this determines the
>>>>initial portion of the string that matches the pattern determined by the
>>>>chars_format parameter, then creates a NTBS to be parsed by strtod (or
>>>>strtold or strtof).
>>>>
>>>>Because creating a NTBS requires allocating memory, but std::from_chars
>>>>is noexcept, we need to be careful to minimise allocation. Even after
>>>>being careful, allocation failure is still possible, and so a
>>>>non-conforming std::no_more_memory error code might be returned.
>>>>
>>>>Because strtod et al depend on the current locale, but std::from_chars
>>>>does not, we change the current thread's locale to "C" using newlocale
>>>>and uselocale before calling strtod, and restore it afterwards.
>>>>
>>>>Because strtod doesn't have the equivalent of a std::chars_format
>>>>parameter, it has to examine the input to determine the format in use,
>>>>even though the std::from_chars code has already parsed it once (or
>>>>twice for large input strings!)
>>>>
>>>>By replacing the use of strtod we could avoid allocation, avoid changing
>>>>locale, and use optimised code paths specific to each std::chars_format
>>>>case. We would also get more portable behaviour, rather than depending
>>>>on the presence of uselocale, and on any bugs or quirks of the target
>>>>libc's strtod. Replacing strtod is a project for a later date.
>>>
>>>two of the new tests FAIL on Solaris 11.3 only:
>>>
>>>+FAIL: 20_util/from_chars/4.cc (test for excess errors)
>>>+UNRESOLVED: 20_util/from_chars/4.cc compilation failed to produce executable
>>>+FAIL: 20_util/from_chars/5.cc (test for excess errors)
>>>+UNRESOLVED: 20_util/from_chars/5.cc compilation failed to produce executable
>>>
>>>Excess errors:
>>>/vol/gcc/src/hg/master/local/libstdc++-v3/testsuite/20_util/from_chars/4.cc:41: error: no matching function for call to 'from_chars(char*, char*, double&, std::chars_format&)'
>>>[...]
>>>
>>>AFAICT that's due to the fact that Solaris 11.3 (unlike 11.4) lacks
>>>uselocale.
>>
>>Ah yes, the tests should not run unconditionally. I'll fix that today,
>>thanks.
>
>This should be fixed at 2251b4a5423efa8ee0d7e67537b63e404a1f6afa.

Oh it looks like I forgot to send that patch to the lists, so here it
is. Tested powerpc64le-linux, committed to trunk.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch.txt
Type: text/x-patch
Size: 5540 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/libstdc++/attachments/20200728/75e3e25e/attachment.bin>


More information about the Libstdc++ mailing list