Sounds like an infinite loop.

can you provide the code

I hope this will resolve this conversation: The answer to your question came from the very first reply you got. You are confused because I don't think you're very familiar with the mechanics of the website. The person who translated this Kata to C++ is a regular user like you and me who hasn't logged in since 2019. It wasn't an admin, so surely nobody has any incentive to deny fixes to the Kata. The reason nothing is being done about is because... there is nothing wrong with the solution. As with most Kata, random inputs are generated by running them through the author's reference solution. Hobovsky (mind you, the first reply to your message) has run the cases you're complaining about through the author's solution - which is the only source of answers/test cases - and found that they indeed produce the correct results. I have just confirmed this. Nobody's being mean, but the issue with the tests is genuinely from your solution's side, and not anybody else's. In fact, once you complete the Kata, you are free to inspect the hell out of the author's solution and the testing code. It's literally all open to anyone.

You do realize the "superusers" are doing this out of their volition and aren't obligated to waste time of their day fixing nonexistent issues with the Kata?

@hobovsky your patience is legendary.

Just done this kata in less than 10 minutes while you're still arguing about how "perfect" your code is and literally everybody else and the tests are wrong for more than 8 hours.

I don't understand why are you so persistent to your code being perfect when there's already 1678 solves in C++. There would've been at least an issue discussing about this if the test is indeed has an error (as a side note, my C++ solution is a port from the JS version, which has 7000 solves and thus strengthen my point on there should be issue opened about this already and should already be fixed).

Lately you have been posting some comments and issue which is not a kata issue at all and in fact your own solution being wrong. On top of that, you are being rude when other people trying to help. Please remove your narcissistic and rude behaviour and try being friendly for once.

I don't know how you can misinterpret what I said in that way. But I'll rephrase what I said, for each char in str2, there should be a corresponding char in str1 and you can't use the same char of str1 more than once to match the chars of str2. I think hobovsky has a typo there and the test should be like this: Assert::That(scramble("a", "aa"), Equals(false));

Your solution returns invalid answer for following test case: Assert::That(scramble("aa", "a"), Equals(false));

Your solution returns true, but correct answer is false.

Your solution has a bug, it's not a kata issue.

My debugger disagrees:

For input "CI", the intvec is {100, 1}, and inen reaches 2.

Except it does not work this way, because you always do inen = i + 1 what causes that even if inen is correct to enter the loop, it becomes too large on the first line of the loop. Your ++inen is in wrong plce, and your loop condition does not protect against the overflow, because the overflow happens in the loop, on the line inen = i + 1, after the inen is checked to be correct. Additionally, the ++inen is inside of an if, so the inen is not always increased.

Now it is my turn to say this: run your code locally, in a step-through debugger, and observe how inen gets too big even after the loop checks that it's correct.

The bug is there always, for every input, not only for "single byte edge cases". On line 164, the intvec[inen] is always out of bounds on the last iteration of the loop.

Your lines 161 to 164 look like this:

         int inen = 0;
         for (int i = 0; inen < sz; ++i) {    
              inen = i+1;
              if (intvec[i] < intvec[inen]) {
                  intvec[i] = 0 - intvec[i];

Let's assume the input is "C". Expected answer is 100, right? Your intvec is { 100 }, which is correct. Its length is 1, and sz = 1.

On line 162, in first iteration of the loop, i is 0.
On line 163 inen is i + 1 which is 1.
On line 164 you do intvec[inen] which is intvec[1] which is out of bounds.

I fixed your solution by adding a single line of code, which neutralized the out-of-bounds access.

One of your indices is out of bounds, in one place, in some cases.

Your code does not work perfectly.

I would recommend reading about vector::at member function, pondering it a bit, understanding what it does, replacing your unchecked index accesses with checked index accesses, and seeing by yourself how your code thwors an exception due to excessive indices.

I don't care if you like my answer or not, but the truth is: inputs given to you are OK (I reviewed code of tests and I printed inputs on CW to see wht they are), and your code is not OK (I read it, I spotted out of bounds access in the code, I changed your code in a way which does not change the logic but adds some checks, and it confirmed the suspicion). What you do with this information is up to you.

And you are warned for use of foul language and advised to watch your mouth.

You really need to pay better attention to other user's profile pictures. Sometimes, they hold valuable clues...

I did run it, locally, and on Codewars. I read the code and i found that some loops sometimes go too far. And after replacing unchecked index access with .at(idx) it throws an exception. Its enough to know that your indices are out of bounds.