FastDoubleParser: Java port of Daniel Lemires fast_double_parser

Code should be written for humans.

I'd far prefer:

    ++index;
    ch = index < strlen ? str.charAt(index) : 0;

C++:

    bool found_minus = (*p == '-');
    bool negative = false;
    if (found_minus) {
      ++p;
      negative = true;
      if (!is_integer(*p)) { // a negative sign must be followed by an integer
        return nullptr;
      }
    }

    int strlen = str.length();
    if (strlen == 0) {
        throw new NumberFormatException("empty String");
    }
    int index = 0;
    char ch = str.charAt(index);

    boolean negative = false;
    if (ch == '-') {
        negative = true;
        ch = ++index < strlen ? str.charAt(index) : 0;
        if (ch == 0) {
            throw new NumberFormatException("'-' cannot stand alone");
        }
    }

I have seen far too many bugs creep in this way. I feel like C/C++ induce a desire to keep the code as short as possible and being 'clever'; even I often feel the need to do that in C++ when I am happy to write a more readable version in other programming languages.

The bugs are also hard to spot when skimming through the code: When there's a lot of code you will often miss the ++ on the 'index' as it's a long line compared to having '++index' on its own line.

Another good 'pet peeve' of mine is the following construct:

  for(int i = 10; i--;)
    // Do something until 'i' reaches 0

That's why I'm building Concise Encoding [1], which is a twin text/binary format that can be 1:1 converted back and forth. You do everything in binary, and only convert to/from text in the few places where a human needs to be involved (like debugging or configuration).

[1] https://concise-encoding.org

In my C# and even in C++, profiler sometimes showed me I am bottlenecked on parsing or printing floats. Happened quite a few times.

In all cases the data was 3D models or similar things. STL, 3MF, VTK, G-mesh, G-code are all text based, either always (looking at you, 3MF consortium) or as an option (STL and some versions of VTK can be either binary or text). Even low-end modern GPUs can easily render 1E+7 triangles these days, thus high-poly 3D models are not uncommon.

Games are not affected because they preprocess the hell out of their assets, optimizing everything they can about the data format. But in CAD/CAM stuff you’re pretty much guaranteed to bottleneck on parsing numbers when loading these text-based formats.

Also, while there are only 2^64 distinct double values, there are many more string representations than that. For example, "1" and "1.0" are the same underlying value, but a parser needs to be able to handle both.