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.

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

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

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

Oh, actually you make a great point, i didnt think about single byte edge cases. Thanks

There is not a single possible occurence in which vector[inen] is called where inen is past the last index of the vector, there is no excessive index and you should understand how vector.end works as a dynamic index and why unchecked index access is used in the first place. The main problem remains, that is random tests being improper.

Can somebody competent who actually writes c++ or C take a look at this issue? I would like to receive funny internet points for my correct code. Thank you very much in advance.

my indices are not out of bounds, run the damn code.

i changed it and it throws an error

YOU CHANGED IT LMAO THIS IS ABSURD

Run the code how i wrote it, it works perfectly. I am sorry that you dont understand cause and effect because you use java and i am sorry that you didnt bring up how the only waty that could caus segfault is through intuitive assembling which does not happen period in this case. Laughable even.

another guy who didnt read the code or test it for himself

fucking lmao

cant understand someone else's code

in stead of reading it again you downvote the guy and grab your second device to upvote your own post

whew.

BTW do you want to fix this kata or not? My code works perfectly and the random tests are fucked.

it isnt a seg fault because that condition is never reach, read the code properly. You didnt even compile and run it...

You actually replied about when i did, I apologize for the mockery

instead of getting butthurt about nothing look at the code. Did you like cry for 10 minutes and then came back to write that? lol.