-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Some more issues about to_chars
#166
Comments
That's how |
@pdimov I mean, |
That should be a bug, then. |
No; it will be fixed by linked PR. |
I believe the difference is between formatting with 1e-4 as the crossover point between fixed and scientific like in your last issue right? Since the goal is the absolute minimum number of characters? https://godbolt.org/z/bnscGEbMn
That does seem to be the case: https://godbolt.org/z/6xPMKeTcM |
Yeah, |
Fix for issue #166 negative precision
It seems that
std::to_chars
returnserrc::value_too_large
rather thanerrc::result_out_of_range
. Is this simply a mistake or do you have a reason for usingerrc::result_out_of_range
instead? In the code I edited I usederrc::result_out_of_range
for consistency.to_chars
with only buffer & value, with the format param as well, and with the precision param as well, all should be separate overloads. The reason why the first and the second should be separate overloads is because the first one should behave differently from the second one withfmt == chars_format::general
; it needs to select whatever representation that is shortest, which does not always need to be equal tochars_format::general
's output. The reason why the second and the third should be separate overloads is because by the spec,precision
being negative should be treated as ifprecision == 6
, because the spec ofstd::printf
says that negative precision is ignored, which means it should fall back to the default, which is 6. I guess this is quite stupid, but well, it seems that's how the spec is written anyway.EDIT: Ah, forgot to mention. When fixed format is chosen for the shortest representation, the output of Dragonbox may not be the correctly rounded one, because there can be trailing zeros in the integer part. (See fmtlib/fmt#3649 for a related discussion in libfmt.)
The text was updated successfully, but these errors were encountered: