@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).
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.
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.
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
sizeofcheck.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
maptofilter(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 bothmapandfilter, 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...