You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
boost is selecting scientific instead of fixed here, even though fixed is shorter.
It seems like it may be an issue with values < 1, since 0.1234 and 0.12345678 also select the longer scientific format, but 1.1, 1.1234, and 1.12345678 select fixed as expected.
The text was updated successfully, but these errors were encountered:
This was discussed at the top of #166 (and the links to FMT and MSVC). The situation was improved earlier this year, but not completely addressed. I'll relook this in a bit.
0.1 is indeed the right output for the example you brought, but according to my understanding of the spec, chars_format::general is not supposed to output the shortest output. Printing the shortest output is the behavior without the format argument, which is supposed to be a separate overload. chars_format::general is supposed to choose between fixed vs scientific based on the decimal exponent, which has little to do with being the shortest. For instance, 0.001 must be printed as such in chars_format::general, but 1e-3 is shorter. That is,
to_chars(first, last, 0.001)
must print 1e-3 while
to_chars(first, last, 0.001, chars_format::general)
Interesting... playing around with it that does indeed seem to be the case with gcc's std::to_chars (although due to the two-digit exponent gcc at least switches over at 0.0001 instead of 0.001 with no format specified).
Would be good if boost supported both the general and shortest cases, but I guess at least the general case would ideally match.
Using to_chars with general format seems to not produce the shortest output in some simple cases.
For example, comparing boost charconv, std charconv (gcc 14), and fmt:
Output:
boost is selecting scientific instead of fixed here, even though fixed is shorter.
It seems like it may be an issue with values < 1, since 0.1234 and 0.12345678 also select the longer scientific format, but 1.1, 1.1234, and 1.12345678 select fixed as expected.
The text was updated successfully, but these errors were encountered: