whatahell

This is absolutely clever but I think it can be hard to read. Also, I think you could have added constants so you don't end up with magic numbers that the next person won't know what they're for.

@IkIkleo @o2001

The value should be an output integer, not an input, which is in string format. Therefore, the function should be able to operate with a string like "1 0000001 0000011 0000021 000003," for example. (Even my function cannot do that, but I found out thanks to this). However, if it is also meant as an input value (string), I won't unnecessarily complicate it.

@IkIkleo Your solution is perfectly correct given the specifications of the problem. The problem description assures you that no single integer would cross 1000000000.

Np ;-)

Oh yes, you are totally right. I will correct my solution for this. Thank you for pointing out.

The error in your code lies in the possibility of attempting to convert an integer larger than its maximum possible value. Specifically, on this line: int start = std::stoi(str.substr(0, i));. I suspect that neither your code nor the server-side compiler addresses this issue, and due to improperly written tests, this error remains undetected.

Hi, as described in "Given a sequence of one or more consecutive natural numbers concatenated into a string", i thought "78910111011" does not fit this describition

this solution is not entirely correct, it does not assign the correct value, for example, with the input '78910111012'. This solution even causes an error in Visual Studio

C++, random tests, given -2, expected 0, i got this. Given -8, expected -168... I though the test range is 0 - 1000

"this" keyword is not needed here. Only if you have same spelling on param and property but you have one starting with capital letter and one starting with non-capital letter

LOL, you made my day!!

They're equivalent in the mathematical sense, but not in the floating-point sense. This is a permanent problem with floating point numbers.
for example, if (r1 + r2) is really small, the precision of its product (r1 + r2) * (r1 + r2) is going to be bad ... so it's better to avoid multiplications if you can in a formula like this
(i didnt look at the JS translation so it's just my guess)