Going for 2000 was a good idea, my brute-force solutions in Java didn't work :'D

Amazing kata, thank you very much!

I think you might be underestimating the power of memcpy :D

Fully agree with this :'D

Agreed. It's not too bad since vectors are cleverly resized under the hood. But you are right, it would be an improvement. Calling the constructor with the size would also be an option. While doing that you could also store the size in a variable and use that for the loop. That should be more efficient, since the compiler probably can't infer that lines.size() is a constant

Yippie! Thank you for all the help! ^.^

approved 🦊

Ouh I see :'D
Should be clear now, I just had to remove the function "hint" for C.
Here is the new fork: https://www.codewars.com/kumite/60d98f1d57c9d500554dff6b?sel=6276990271e24f0016c113cd

there is a merge conflict because the the kata's description has been modified since the time you started this translation. you need to fork this kumite so that the description is updated; and publish the new fork. let me know if it's clear ^^

Very nice, thank you for the feedback!

Dang it, I completely forgot about that. Glad you mentioned it ^^'
Should be fixed now!

• it's OK if you keep num_elements imo, now that it is used as a length hint for the array
• it's fine if you do not want to write code to print the pyramid, other languages do not do it either. it's just a nice touch that makes debugging easier, but it is not considered mandatory on codewars
• one thing I completely forgot : all of the functions that are in the tests should be declared static. This avoids the user calling your reference solution or trying to manipulate the random numbers generator; and it's also good practice to avoid namespace pollution.

Hey there ^^
Thank you very much for taking the time to give some really nice feedback! I greatly appreciate it.
I think that I included all of your suggestions. I, unfortunately, didn't have the time to print the pyramids. In the case of the sample tests they are visible, but for the "more elaborate" tests it might be worth to add them (for the smaller ones). Let me know what you think, then I'll take some time :D
Oh and regarding the suggestion with the num_elements, the C99 style seemed like a good idea to me. I didn't want to "burden" people with figuring out that you can use gauss to "derive" the number of elements from rows. My reasoning was that other languages (afaik) did not require that, but let me know what you think!

Cheers ^^

• no feedback on failure: you have to ovveride the default assertion message like so:
  cr_assert_eq(actual, expected, "expected %d but got %d", expected, actual);
  You could also (optionally) print pyramids when they are not too huge

• rows = rand() % 101;
  if (rows == 0) rows = 1;
  

=> more tersely :

rows = 1 + (rand() % 100);

• Could you use C99 parameter declarations and change

  int pyramid_slide_down(const int pyramid[], int num_elements, int rows)
  

  to

  int pyramid_slide_down (int num_elements, const int pyramid[num_elements], int rows)
  

  ? either that or get rid of num_elements, as it is not strictly necessary to solve the task, and unused parameters trigger warnings, except when they are length hints for other parameters

• 1 sample test is too little. I would add a couple, including an edge case where the pyramid has only 1 row

• the initial solution setup does not clearly explain the memory model of pyramid, especially considering most other languages use 2D arrays. I suggest a message along the lines of :

pyramid is a one-dimensional array containing the elements of a pyramid with rows levels, in direct succession from left to right, top to bottom`

Cheers :)