New function from splitting Strtod? about double-conversion HOT 6 CLOSED

I would be ok with a different function, but TrimAndCut also ensures that the given buffer doesn't have too many digits.
This happens in two steps:

1. the trailing '0' digits are removed (while updating the exponent), and
2. the digits are "cut" off if there are too many.

Sounds like a very special case where you are sure that you will never need this.
It might be more interesting to add a shortcut to the Strtod function that checks rapidly whether the buffer starts with non-'0' and ends with non-'0', and is short enough.

Wdyt?

from double-conversion.

Our parsing front-end also checks the number of digits before copying them (we'd do zero-copy, but that's not generally possible due to the decimal point, and I haven't been bother to try something else for using the input's buffer in-place). We really just need the back-end conversion without any checks at all because that seems to be the most efficient way of bolting your Strtod() to our library.

Btw, it was mostly thanks to double-conversion that our JSON library achieved 100% conformance in the nativejson-benchmarks, if you happen to know that. Integration was a bit of an effort since we are currently header-only, and had to make the parts of double-conversion that we need header-only, too, but definitely worth it.

(The plain grammar accepts any number of digits, but the semantic actions that prepare the character array with the digits, and the int with the exponent, do all size checks, and strip trailing zeros before copying them; as mentioned the grammar itself doesn't allow leading zeros.)

https://github.com/taocpp/json/blob/master/include/tao/json/internal/grammar.hpp
https://github.com/taocpp/json/blob/master/include/tao/json/internal/action.hpp
https://github.com/taocpp/json/blob/master/include/tao/json/internal/number_state.hpp
https://github.com/taocpp/json/blob/master/include/tao/json/external/double.hpp

from double-conversion.

Having a separate function is fine then.

I think I would call it StrtodTrimmed. You can refer in the documentation to TrimAndCut, and mention that most users probably don't need it (and should use Strtod instead).

I don't think there is a need to add StrtofTrimmed (unless you need it) already now. Can easily be added at a later point.

For good measure I would add an ASSERT to check that the buffer that is given to StrtodTrimmed is the same as the one after TrimAndCut.

I don't think you need to add lots of tests. However, I would test the corner cases, like the longest possible numbers, 0, ...

from double-conversion.

We don't need it for floats, and StrtodTrimmed() is fine.

And: You mean the assert should copy the input, pump it through TrimAndCut(), and then assert that neither the data nor the exponent changed?

from double-conversion.

Yes. I would try to add such an assert.
It's not strictly necessary, but nicely shows the expectations of the function (and potentially catches bugs).

from double-conversion.

PR created, we can continue discussing there.

from double-conversion.