Text format (e.g. IridasCube) parsing optimizations

[aras-p]

Primarily driven by a wish to increase performance of parsing .cube files. But the functions that are added or changed are used across parsing of all/most of text based formats.

With these changes, parsing "Khronos PBR Neutral" Iridas .cube file (5.4MB) on Ryzen 5950X / VS2022 Release build: 167ms -> 126ms. Parsing the same file in CLF format: 150ms -> 137ms.

What the PR does is:

• Add locale independent IsSpace(char). Somewhat similar to 3aab90d, whitespace trimming perhaps should not be locale dependent.
• Add IsEmptyOrWhiteSpace() and use that inside ParseUtils::nextline, instead of doing Trim(line).empty().
• Add StringUtils::StartsWith(char) and use that in various parsers that were constructing whole std::string object just to check for a single character.
• When building for C++17 or later, NumberUtils can use standard <charconv> from_chars functions (except on Apple platforms, where those are not implemented for floating point types as of Xcode 15). This has advantage of not having to deal with errno or locales. Saves some thread local storage accesses and function calls (e.g. on Windows errno is actually a function call).
  • Turns out that NumberUtils::from_chars was only indirectly covered by tests, and as XML parser utils tests point out,
    it should be able to handle hex floats and so on. So all that is implemented there, and explicitly covered by
    tests/utils/NumberUtils_tests.cpp.
  • There's a CMake setup change that adds /Zc:__cplusplus flag for MSVC; for backwards compat reasons it does not report proper C++ version detection defines otherwise.

[remia]

Apologies for the delay in CI @aras-p, we have to manually approve the workflows due to our current GitHub settings. Trying to see if we can update that or merge your other PR which should also work.

[aras-p]

@remia thanks! I admit I did not expect that this PR would need so many failed iterations. <charconv> is a tough beast, it seems :)

[remia]

Doing some test on an Intel MBP, Xcode 16, it seems to still not support from_chars(). I did some quick benchmark and found nice speedups to load the same pbrNeutral.cube (from 140ms to 85ms on average to instanciate a Processor with the FileTransform pointing to the cube). Tested on a .spi3d file but this didn't seem to change the timings.

Looks good to me otherwise, thanks for the additional unit tests!

[cozdas]

Minor but to make sure:
Seems like __cpp_lib_to_chars "feature-test macros" are standardized in C++20, If I understand correctly -in theory- a C++17 compiler may not have this macro defined even if from_chars are implemented, thus we may have a false-negative here. Is that correct?

The worst case it'll fall back to slow path, so that's totally fine but I'm just curious.

[aras-p]

In theory, yes. In practice, this was the "least bad" way I found that would work on all of MSVC/clang/gcc, while also working on Apple Clang (in a sense that Apple Clang does not pass the test; from_chars on floats is still not there). In theory there could be some exotic compiler that might have from_chars for floats but not expose __cpp_lib_to_chars.

[aras-p]

Doing some test on an Intel MBP, Xcode 16, it seems to still not support from_chars()

Yeah, Apple's Clang/STL keeps on being "special". Some other software (e.g. Blender) works around this whole issue by embedding https://github.com/fastfloat/fast_float and using that instead of <charconv>