Skip to content
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

Consider fast_float and std::from_chars #3

Open
alugowski opened this issue Jul 7, 2023 · 2 comments
Open

Consider fast_float and std::from_chars #3

alugowski opened this issue Jul 7, 2023 · 2 comments

Comments

@alugowski
Copy link

Great library!

I did notice that the integer and floating-point routines parsing are home-grown. They do seem to perform well and handle common values well, but it's easy to see places where they'd break down.

I faced the same problem and settled on fast_float for floats and std::from_chars for integers. The former has basically the same performance as read_fp, but can be considered correct (including error checking!). It's already been, or soon will be, included in all the major compilers. The latter has basically universal compiler support. I don't see a minimum C++ standard declaration anywhere, so I assume C++17 is ok.

@kasimirgabert
Copy link
Member

This is a great suggestion. For the systems that this library was built for (and currently used on), C++11 through older compilers is all that is available. However, from_chars and fast_float would be perfect for those that can use it. The current plan is to develop a parameter that can allow different character and float parsing to be used, with the homegrown one an option available for those that do not have access to other implementations.

@alugowski
Copy link
Author

fast_float itself is C++11, it just uses an interface similar to the C++17 routines. Only std::from_chars requires C++17.

I'm noticing not too much downside with strtol and friends for integers, though I bet your homegrown is faster. I'm too paranoid of missing some edgecases to use a homegrown solution. For example the homegrown does not appear to detect overflow. That's probably a worthwhile tradeoff for many users though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants