Should have just divided the num by 10 each time

Best practices vote, well done.

std::map is actually O(logn) to find. A hashmap (std::unordered_map) would be what to use for efficiency

Viewbox is a completely different concept from Paths, so no. Viewbox only specifies where in the canvas you're looking at. The actual location of the path is specified by its own coordinates.

If you have multiple paths and you want to transform some of them, moving the viewbox will not achieve the goal. You'll need to actually transform the paths.

Q: shouldn't all this be handled through the viewbox, normally? (I mean: does the kata actually make any sense? Is there a situation where it's sensical to proceed with a complete update of each path?)

SVG spec allows for 1 or more set of parameter values for each command; this is not tested at all. ALl tests only test 1 set of params per command.

All random tests (and some fixed tests) are run outside it blocks. This messes up with logging in user code, they now all clump before the first test block and there are no ways to figure out which log corresponds to which test.

exactly what I thought :'(

Everything should work fine now.

I made some changes in the description and added some examples.
Please take a look.

(And, I got to use the word "behemoth". I like that word!)

It IS an issue. The specification is vague, but says:

The words in the array should mesh together where the last few letters of one word will have the same letters (in the same order) as the next word in the array. (emphasis added)

The spec should be more precise than this, but whatever 'few' means, it doesn't really mean 'all'. Spec should be changed.

My thought as well.

Thanks for your response, it's great to see the alternatives. I quite like the second way you suggested to keep it semi simple and on 2 lines.

Also I've bookmarked the gitter link for future