What should the output of to_chars(123456789.0, chars_format::general) be?

[statementreply]

Current implementation: 1.23456789e+08
My understanding: 123456789

[charconv.to.chars]/2

The functions that take a floating-point value but not a precision parameter ensure that the string representation consists of the smallest number of characters such that there is at least one digit before the radix point (if present) and parsing the representation using the corresponding from_­chars function recovers value exactly.

[Note 1: This guarantee applies only if to_­chars and from_­chars are executed on the same implementation. — end note]

If there are several such representations, the representation with the smallest difference from the floating-point argument value is chosen, resolving any remaining ties using rounding according to round_­to_­nearest.

[charconv.to.chars]/3

The functions taking a chars_­format parameter determine the conversion specifier for printf as follows: The conversion specifier is f if fmt is chars_­format​::​fixed, e if fmt is chars_­format​::​scientific, a (without leading "0x" in the result) if fmt is chars_­format​::​hex, and g if fmt is chars_­format​::​general.

[charconv.to.chars]/11

Effects: value is converted to a string in the style of printf in the "C" locale.

My understanding is that for general shortest, the output is in the same format as printf with g specifier and an appropriate precision satisfying the shortest text requirement (at least 9 in this case). Missing precision parameter in to_chars doesn't mean unspecified precision in printf, so default P = 6 isn't applicable here (xcharconv_ryu.h:1335).

123456789 can be produced by printf("%.9g", 123456789.0); 1.23456789e+08 can't be produced by printf g format with any precision.

Question 2: should the output of to_chars(1e+4, chars_format::general) be 10000 or 1e+04?

[StephanTLavavej]

I found the Standardese here to be unclear, and explained my reasoning on Reddit last year. The central question is indeed what P should be, and the confusion is caused by the Standardese being split between C and C++. Your Question 2 about 10000 is essentially the same as my 1700 scenario.

My interpretation was that printf's "style" is used to decide between fixed and scientific, and I considered the P = 6 default to be applicable, because the precision was indeed omitted in the to_chars call. But the actual number of digits being printed is controlled by the C++ Standardese. This is indeed a different interpretation than behaving like %.*g with a magically varying runtime precision - that would produce results also obtainable from printf, but not "really", because nothing in the C Standard Library can compute the shortest round-trip precision.

The advantage of this P = 6 interpretation is that it produces results much like printf %g (equivalent to %.6g) and the iostreams default, for reasonable-sized values. It would be very surprising to most users for "1e+04" or "1.7e+03" to be printed, when they've simply asked to_chars to switch to scientific notation for extremely large or extremely small values with chars_format::general. The P = 6 interpretation means that to_chars will have the same switchover points as %g, except that it will print extra digits to preserve the round-trip property (which the user definitely requested).

Here's an example that shows why I believe that the current implementation captures the Standard's "style of printf" intent:

C:\Temp>type meow.cpp

#include <charconv>
#include <cstdio>
#include <cstdlib>
#include <iterator>
#include <system_error>
using namespace std;

void test_general(const double dbl) {
    char buf[24]; // worst case "-1.2345678901234567e-100"
    const auto result = to_chars(buf, end(buf), dbl, chars_format::general);
    if (result.ec != errc{}) {
        puts("FAIL");
        exit(EXIT_FAILURE);
    }
    printf("%-11g | %.*s\n", dbl, static_cast<int>(result.ptr - buf), buf);
}

int main() {
    printf("printf %%g   | to_chars general\n");
    test_general(0.123456789);
    test_general(0.12345678);
    test_general(0.1234567);
    test_general(0.123456);
    test_general(0.12345);
    test_general(0.1234);
    test_general(0.123);
    test_general(0.12);
    test_general(0.1);
    test_general(1.0);
    test_general(12.0);
    test_general(123.0);
    test_general(1234.0);
    test_general(12345.0);
    test_general(123456.0);
    test_general(1234567.0);
    test_general(12345678.0);
    test_general(123456789.0);
    printf("\n");
    printf("printf %%g   | to_chars general\n");
    test_general(1e-9);
    test_general(1e-8);
    test_general(1e-7);
    test_general(1e-6);
    test_general(1e-5);
    test_general(1e-4);
    test_general(1e-3);
    test_general(1e-2);
    test_general(1e-1);
    test_general(1e0);
    test_general(1e1);
    test_general(1e2);
    test_general(1e3);
    test_general(1e4);
    test_general(1e5);
    test_general(1e6);
    test_general(1e7);
    test_general(1e8);
    test_general(1e9);
}

C:\Temp>cl /EHsc /nologo /W4 /std:c++17 meow.cpp && meow
meow.cpp
printf %g   | to_chars general
0.123457    | 0.123456789
0.123457    | 0.12345678
0.123457    | 0.1234567
0.123456    | 0.123456
0.12345     | 0.12345
0.1234      | 0.1234
0.123       | 0.123
0.12        | 0.12
0.1         | 0.1
1           | 1
12          | 12
123         | 123
1234        | 1234
12345       | 12345
123456      | 123456
1.23457e+06 | 1.234567e+06
1.23457e+07 | 1.2345678e+07
1.23457e+08 | 1.23456789e+08

printf %g   | to_chars general
1e-09       | 1e-09
1e-08       | 1e-08
1e-07       | 1e-07
1e-06       | 1e-06
1e-05       | 1e-05
0.0001      | 0.0001
0.001       | 0.001
0.01        | 0.01
0.1         | 0.1
1           | 1
10          | 10
100         | 100
1000        | 1000
10000       | 10000
100000      | 100000
1e+06       | 1e+06
1e+07       | 1e+07
1e+08       | 1e+08
1e+09       | 1e+09

So my answer is: This was intentional, although I will be interested to see what libstdc++'s independent implementation does (I saw that @jwakely is using Ryu, but this logic is outside Ryu itself). I would also prefer for the Standardese to say something clearer here. One of @jwakely's Proposed Resolutions for LWG-3456 makes the from_chars Standardese more standalone and something similar could be done for to_chars.