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.

I have repeated 10 times that the bug that is being brought up is utterly irrelevnat to the discussion. from_roman is broken and you have been ignoring that and attacking a red herring for 30 posts acting like absplute redditors. Unbelievable.
Fix your shit, I am not going to use a site that sweeps problems under the rug and reinforces their stupidity by clicking le funny updoot, a rush of dopamine wiping away worries. Keep your broken kata, if people solved it its because they strayed away from the description and shaped their code to the solution conditions in stead of tasks.

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.

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));

thats literally the one word edge case that I have conceded on!? (admittedly i said byte). Why are you shifting goalposts? Also, in an earlier post you say that you "fixed my code" ut no you did not, as I had already said the problem was in a completely different function. I am passing all of the to_roman tests and the from_roman basic tests while from_roman random tests fail here but all work perfectly on my machine (single word ones too now that a clause was added). Kata is broken.

Complete the function scramble(str1, str2) that returns true if a portion of str1 characters can be rearranged to match str2, otherwise returns false

It seems like ("aa", "a") should pass by the test description? I added a condition where if only 1 char was present in s2 the function would return false (the idead was that 1 char wouldnt be considered a "string" by the author which is flat out wrong but i digress). I thought that maybe all of the characters in str1 being in str2 would be a fail condition but the following, one of the basic tests refutes that idea. [code] Assert::That(scramble("commas", "commas"), Equals(true));[/code]

I also came across a post by user Chrono79 (right under this thread) which could be misinterpreted as ^a character being present in str2 twice is a fail condition" but that is disproven by the following basic test [code] Assert::That(scramble("katas", "steak"), Equals(false)); [/code]

This is a blatant kata issue.

edit: grammar

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.

it does not become too large? example:

size is 5; i = 0 && inen is 1 && last line inen is 2, i = 1 && inen is 2 && last line inen is 3, i = 2 && inen is 3 && last line inen is 4, i = 3 && inen is 4 && last line inen is 5 LOOP ENDS. It werks, I dont and will not use a debugger, I am reading to dim with assembly and in this instance where i cant yet read it i luckily know that inen is fine

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.

it isnt, there is a reason for the last line

"++inen"

inen is the one being checked in the condition and that is the reason i declare inen outside of the for loop.

Lets say size is 10 and i is 8, i have now checked the 8 and 9 indexes of the vector, ++inen and the loop doesnt run again.

edit:clarified and fixed a grammatical mistake

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.