Jens Yllman

cppreference state, "std::move is used to indicate that an object t may be "moved from", i.e. allowing the efficient transfer of resources from t to another object. In particular, std::move produces an xvalue expression that identifies its argument t. It is exactly equivalent to a static_cast to an rvalue reference type. " Which kind of say it is never a move, only a conversion of type, which may result in a move. But in this case it will only be a reference to the value. Or am I wrong? Looking at...

Hmmm, I wonder how well cppcheck handles other special values in IEEE854.

For me the size check is not the most important here. Taking a pointer to a pointer is somewhat suspicious to me. And also the cast, especially since it is a cast from ptr* to ptr. But of curse the size also makes it more suspicious.

Yes and no. I could see things you would like to remove/reduce. But the real reason for the really slow execution was that instead of having more or less 'flat' flow with only one level of recursion there was overflow which caused where much recursion and very slow.

No, it did not. And now when I found the real problem the flamegraph is really boring.

So, the use of isKeyword() might be good. But with the 'fix' I put in as a PR #4235 this optimization might not be so needed. The fix instead tries to stop overstepping endToken in the loop in forwardRange().

To me now, it looks like even if you have an endToken into forwardRange() it continues past that end token cause some actions will end on the endToken, and then there is a ++ end then a check if endToken. But then we are past already.

Actually, it seem that the thing that triggered the scan to the end of the file is that in the example file in #10933 the if conditions are actually assignments not compare. So I am now looking on the code in forwardRange() that looks at the condition. If you change the ifs to == instead of = it finishes in no time.