You also modified the input, which was const to begin with.

Agreed. I think it would help, also, to actually be able to downvote best practice.

A solution that I would like would be that you'd actually have to write a word or two on why you think it is a good solution. Then whomever reads the comments can also value each vote according to his or hers own values.

Another solution would be that "best practice"-points are awarded for receiving said points from other people and that for each level achieved, you are awarded a number of "best practice"-points to mete out by default.

Nice! Similar to my solution, but I forgot about lambdas in C++11 and did not know about emplace!

Man, I thought my solution was smart. But of course, this is better. Nice.

To me, this is a good solution, uses available STL functions and is quite readable.
However, it could be improved by not having so much going on on the return-line. This is not a competition to write the fewest lines.
If you want to be the envy of your coworkers in the future, write readable code.

Also, this might be a consequence of the platform, but you should never write code in your class declaration. Always, ALWAYS put the code in the implementation.

Nice kata that tests a lot of things that will confuse and cause intermittent memory allocation problems, however the tests do not catch these faults.

You need to add tests that verify that the solutions:

1. Do not fail to work if the input string lacks null termination (the description never mentions that the string has this, so this should not be guaranteed).
2. Do not write beyond allocated memory (a lot of solutions forget to allocate memory for null termination when they use it).
3. Do not overwrite write protected memory (your example tests use write protected memory but currently just crash if the solutions write in them). This might not be solvable (I haven't myself written any kata yet).

You are using calloc, which guarantees zeroed memory, however, you are not leaving any room for the null termination. strcpy will not care that you have allocated 1 byte too little and will overwrite whatever is after that piece of memory you just allocated. This is a serious problem! Always use strncpy. However, in this case, strncpy would have refrained from null terminating your string, instead leaving you with an unterminated string for all your printfs and your zero termination check. That this passes the tests is more because the tests are bad rather than that your code functions correctly.

You have a bug in your program. Use strncpy instead of copying the string yourself. You are adding one extra character to the end, I presume to get the null termination. However, "malloc" is not guaranteed to returned zeroed memory. There is very likely garbage in that memory so the last byte in that string may not be 0! If you use strncpy, that function will terminate the string for you.

Don't be afraid to add spaces and line breaks to make the code more readable. Name your variables well so that they are called what they are.
When you're working with other people readability is the number one criteria for well written code.
This even goes for yourself, don't write code that you understand now, write code that you'll understand in a year, when you have to do maintenance on it. :)

Modulo (%) is very slow. To find out if a value is odd or even, just extract the lowest bit. Like this: x & 1
so, your "is_odd"-function above could just return v & 1.