@avighna the solution setup had already had extern malloc
The function declaration in comment char *play_pass(const char *phr, int shf) prompts that phr is const and should not be modified!
Anyway thanks for adding the comments in description!
But now your fork can only be approved by the author or admins.
Exact floating-point equality is completely fine in this kata. Floating-point computations are not random. All rules are specified in the description (make sure that everything is evaluated from left to right and use the most precise conversion from strings to numbers).
I am not the Nasm translator and know nothing to Nasm. Maybe you could add a small note for Nasm but ask Hobosky (who is a big chief here) for what you can add. I know nothing of that translation but seeing other's solutions it seems usual to use "malloc" and add "extern malloc"...
count_if seems that it should actually be slower than a simple for loop, unless it inlines the passed function.
Even then, it can't be faster than a simple for loop, and usually for loop is easier to read.
So what makes "count_if" better than a simple for loop?
It is best practice because instead of implementing your own counting function, you use the standard library one count_if. I do agreed it is hard to read if you have no idea what you are looking at; perhaps comments would've made this easier to understand
This comment is hidden because it contains spoiler information about the solution
Fixed the precision of printed values.
This comment is hidden because it contains spoiler information about the solution
Those informations are better in solution set up.
@avighna the solution setup had already had
extern mallocThe function declaration in comment
char *play_pass(const char *phr, int shf)prompts thatphris const and should not be modified!Anyway thanks for adding the comments in description!
But now your fork can only be approved by the author or admins.
@g964
The fork is ok!
've thought that it is clear from the function header to allocate memory yourself...
Exact floating-point equality is completely fine in this kata. Floating-point computations are not random. All rules are specified in the description (make sure that everything is evaluated from left to right and use the most precise conversion from strings to numbers).
I was just blindly going by the System V ABI calling convention ( here under 'System V' https://en.wikipedia.org/wiki/X86_calling_conventions#System_V_AMD64_ABI )
@hobosky: could you see and approve the Nasm fork?
I am not the Nasm translator and know nothing to Nasm. Maybe you could add a small note for Nasm but ask Hobosky (who is a big chief here) for what you can add. I know nothing of that translation but seeing other's solutions it seems usual to use "malloc" and add "extern malloc"...
This probably means that your solution does not handle memory allocation of resulting buffer correctly.
Which is kinda difficult to do, because requirements for memory allocation are not specified at all.
This comment is hidden because it contains spoiler information about the solution
After 6 hours making diagram on miror my brain just stopped.
I well end later
count_if seems that it should actually be slower than a simple for loop, unless it inlines the passed function.
Even then, it can't be faster than a simple for loop, and usually for loop is easier to read.
So what makes "count_if" better than a simple for loop?
It is best practice because instead of implementing your own counting function, you use the standard library one
count_if. I do agreed it is hard to read if you have no idea what you are looking at; perhaps comments would've made this easier to understandLoading more items...