• hard as hell if you don't know templates that well, like me

  • @sv90 are you going to address this issue somehow? If not, I think I'll open an issue on CW github, so that the community can decide what do with these 2 katas (unless somebody comes up with a reason why none of them should be approved at all - in fact, these katas might become obsolete with the introduction of C++20 support on CW in the future, so this case is quite possible too).

  • This solution should be blocked as well, it's bypassing the sizeof check.

  • This solution shouldn't pass, but it currently passes (sometimes, since it takes almost 12s to run), which means test case sizes need to be increased.

  • Awesome, I checked your code, Time: 3963ms, damn)
    My code time is 11 sec XD

  • This comment is hidden because it contains spoiler information about the solution

  • This comment is hidden because it contains spoiler information about the solution

  • Raising an issue here as this kata shares a problem with its sibling.

  • The transform and filter katas are really nice, figuring out all the stuff required to implement a proper generic C++ iterator and please the type system was really interesting and challenging. But at the same time it's really bad that you authored 2 separate katas on the same topic. The solution to both of them is almost identical, the changes required to convert map to filter (or vice-versa) are trivial, and as soon as one kata gets approved, the other will instantly turn into a duplicate. You should either rework them into one asking to implement both map and filter, or simply unpublish one of the katas, as they will not survive together.

  • There should also be small random tests.

  • Yes, ease on the eyes

  • This comment is hidden because it contains spoiler information about the solution

  • The problem states that performance matters, so I think the top spot should be the most readable solution with a O(n) complexity. I'm not saying mine should be there ;) As for the bug, I think you're being a little hard on me. The "bug" requires a string with at least 2GB of the same character (if int is 4 bytes, depends on the platform).

    Edit: I've "fixed" my solution by using string's size_type. It is slightly less readable though because now the type is unsigned.

  • This solution is very idomatic and easily read. So it deserves it's spot at the top.

    Your solution has a hidden assumed limit and a bug on the ammount of any specific symbol appearing in the string.
    If s1 contains MAX_INT or more appearances of a single character your solution starts returning the wrong output.

  • Loading more items...