Loading collection data...
Collections are a way for you to organize kata so that you can create your own training routines. Every collection you create is public and automatically sharable with other warriors. After you have added a few kata to a collection you and others can train on the kata contained within the collection.
Get started now by creating a new collection.
Just curious, how would you expand the query to include months with no payment information in the output?
Old question, but since there's no answer yet:
That's how arithmetic operations work in most programming languages, and sql. If you have an operation, e.g. "+" on two different types, the runtime tries to match the types, usually by casting the "lower precision" type value to the "higher precision" type. The result is then of the common higher precision type. If you transform (or better cast) one value to a data type with higher precision, the other operand will be casted automatically to match. (e.g. int + int = int, float + int = float, float + double = double) If such a conversion is not possible you get an error.
This comment is hidden because it contains spoiler information about the solution
How did this compile? I had a very similar solution but I got a compiler error about undefined reference to ackermann::value.
This could be fixed by creating an instance of the static value (see Unnamed's solution) or using an enum.
I didn't particularly like this kata. We are dealing with randomnes here, which makes the tests unreliable. Even a correct solution might fail at times. Imagine such a behaviour on a real build/test server for real projects.
There's probably no performance benefit over a well written loop. But the standard algorithms are allways better than a bad loop. The real benefit is in "readability of intention". In nested loops it's hard to see what was intended, the standard algorithms state pretty well what they are doing, e.g. copy something if -a condition is true- and you can be sure they do that correctly and efficiently. I must admit that the (nested) lambdas look a little scary at first, but once you get the hang of it the code becomes easier to understand.
Looks pretty similar to my first solution. For readability I moved the code of the lambda expressions into separate functions and used std::bind to make the predicates.
The C++ given stub and test code doesn't even compile. In any case it should be std::vector.
In C++ 11 or 14 the vectors should be initialized by initializer lists like this instead:
This solution will fail if there are more than 101 followers. There's no need to write your own "number to string". Since C++11 there's std::to_string which will do the trick.
Copying all the names to another vector and counting them is a lot of unnecessary work. Use vector::size() to get the count and don't copy anything.
This solution is a little scary. sprintf is one excellent way to get buffer overflow vulnerabilities.