ARROW-18350: [C++] Use std::to_chars instead of std::to_string

[pitrou]

std::to_chars is locale-independent unlike std::to_string; it may also be faster.

This PR does neither bother with test and benchmark files, nor with debug output strings.

Unfortunately, some standard libraries don't provide a full implementation of std::to_chars, in which case std::to_string is still used for the unimplemented input types.

[github-actions]

https://issues.apache.org/jira/browse/ARROW-18350

[github-actions]

⚠️ Ticket has not been started in JIRA, please click 'Start Progress'.

[pitrou]

Darn, std::to_chars is not implemented for floating-point on all C++ standard libraries :-(
https://stackoverflow.com/questions/63963961/what-is-the-correct-way-to-call-stdto-chars

[westonpace]

Looks useful. Thanks!

Are there any cases where std::to_string should be preferred you think? Or, are most formatting functions that output to the user already going through some other kind of string formatting function?

[westonpace]

I believe this is redundant: https://godbolt.org/z/6vcW1jEfh

The call to resize should set out[length] to 0 so that std::string can fulfill its requirements for c_str.

That being said, it should be harmless and I imagine would optimize out.

[pitrou]

Hmm, you're right, we shouldn't need to do this on our own.

[pitrou]

Are there any cases where std::to_string should be preferred you think?

I don't think so (unless locale-dependence is desired).

Or, are most formatting functions that output to the user already going through some other kind of string formatting function?

Places where performance is important generally use our home-grown formatting routines, yes.

[pitrou]

@bkietz Can you think of a simple way to solve the incompleteness issue?

Darn, std::to_chars is not implemented for floating-point on all C++ standard libraries :-(

[westonpace]

@pitrou maybe this (gist, godbolt)? It's a mix of sfinae (the int version is preferred over the long version) and constexpr.

[pitrou]

@westonpace Thanks a lot. I'm trying to come up with a more condensed version.

[pitrou]

@github-actions crossbow submit -g cpp

[pitrou]

@github-actions crossbow submit -g cpp

[pitrou]

Wow, turns out <charconv> isn't even provided in some cases.

[pitrou]

Revision: 32f378c

Submitted crossbow builds: ursacomputing/crossbow @ ARROW-18350-to-chars-0

Task	Status
test-alpine-linux-cpp
test-build-cpp-fuzz
test-conda-cpp
test-conda-cpp-valgrind
test-cuda-cpp
test-debian-10-cpp-amd64
test-debian-10-cpp-i386
test-debian-11-cpp-amd64
test-debian-11-cpp-i386
test-fedora-35-cpp
test-ubuntu-18.04-cpp
test-ubuntu-18.04-cpp-release
test-ubuntu-18.04-cpp-static
test-ubuntu-20.04-cpp
test-ubuntu-20.04-cpp-20
test-ubuntu-20.04-cpp-bundled
test-ubuntu-20.04-cpp-thread-sanitizer
test-ubuntu-22.04-cpp

[pitrou]

I'm gonna merge now that CI is green.

[wgtmac]

On my Mac M1 laptop, the compilation looks good but linking complains about undefined symbols:

[ 63%] Built target arrow-io-file-test
[ 63%] Built target arrow-io-memory-test
[ 63%] Linking CXX executable ../../../debug/arrow-utility-test
Undefined symbols for architecture arm64:
"std::__1::to_chars(char*, char*, double)", referenced from:
std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > arrow::internal::ToChars<double>(double) in string_test.cc.o
"std::__1::to_chars(char*, char*, float)", referenced from:
std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > arrow::internal::ToChars<float>(float) in string_test.cc.o
ld: symbol(s) not found for architecture arm64
clang-14: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [debug/arrow-utility-test] Error 1
make[1]: *** [src/arrow/util/CMakeFiles/arrow-utility-test.dir/all] Error 2
make: *** [all] Error 2

It looks like I am hitting an old issue: https://stackoverflow.com/questions/58923623/stdto-chars-compile-but-not-linking-on-macos-clang/59672017#59672017

BTW, my clang version is as below:

➜ clang -v
Homebrew clang version 14.0.6
Target: arm64-apple-darwin21.6.0
Thread model: posix
InstalledDir: /opt/homebrew/opt/llvm@14/bin

[pitrou]

@wgtmac Sigh :-( As I understand it, you should be able to upgrade your Mac to a newer libc++ version (not sure how that's done, though)?

[ursabot]

Benchmark runs are scheduled for baseline = 62829c5 and contender = ad54d6c. ad54d6c is a master commit associated with this PR. Results will be available as each benchmark for each run completes.
Conbench compare runs links:
[Finished ⬇️0.0% ⬆️0.0%] ec2-t3-xlarge-us-east-2
[Finished ⬇️0.34% ⬆️0.0%] test-mac-arm
[Finished ⬇️0.0% ⬆️0.0%] ursa-i9-9960x
[Finished ⬇️0.45% ⬆️0.07%] ursa-thinkcentre-m75q
Buildkite builds:
[Finished] ad54d6ca ec2-t3-xlarge-us-east-2
[Finished] ad54d6ca test-mac-arm
[Finished] ad54d6ca ursa-i9-9960x
[Finished] ad54d6ca ursa-thinkcentre-m75q
[Finished] 62829c5c ec2-t3-xlarge-us-east-2
[Finished] 62829c5c test-mac-arm
[Finished] 62829c5c ursa-i9-9960x
[Finished] 62829c5c ursa-thinkcentre-m75q
Supported benchmarks:
ec2-t3-xlarge-us-east-2: Supported benchmark langs: Python, R. Runs only benchmarks with cloud = True
test-mac-arm: Supported benchmark langs: C++, Python, R
ursa-i9-9960x: Supported benchmark langs: Python, R, JavaScript
ursa-thinkcentre-m75q: Supported benchmark langs: C++, Java