Resu can become unnecessarily huge for large values of n.

I guess great minds think similarlly ;).

That's really clever, but it's undefined C (that is, side-effect operations with binary operations yield undefined effects). And the strict defintion of "undefined behavior" means allowing the compiler to do anything it chooses.

For C++, I honestly think the random tests have a bug. For example, for this list

180, -85, 196, 88, 65, -22, 8, -86, -37, 85, -70, -82, 87, -54, -99, -163, -75, 107, 56, 191, -141, 22, -179, -199, -47, 134, 69, 49, 93, -16, -193, 120, -182, -110, -151, 104, -57, -156, -124, -148, 18, 76, -137, 80, 192, -36, 23, 152, 176, 6, -144, 124, -184, 126, -42, 112, 47, 68, -105, -3, 13, -104, 84, 39, -103, -154, 19, -100, 27, -122, -177, -32, -119, -79, 75, -20, 67, -72, 

The test harness says the answer should be to remove "196" whereas my code says "-199", which according to Excel, is the smaller q value (1.0269E-140 for -199 vs 1.4917E-140 for 196).

This appears to have NOT been resolved. For n = 63, there an overflow even with the C unsigned long long type. For that series, the last two numbers overflow:

GIVEN: ... 4'611'686'018'427'387'904, 3'236'635'425'598'607'970, 12'460'007'462'453'383'777

EXPECTED: ... 4'611'686'018'427'387'904, 9'223'372'036'854'775'808, 18'446'744'073'709'551'615  < -- this last number given by the test harness is oddly ULLONG_MAX. 

I recommend stopped at n = 62 (this would also correct the bogus range of the "High Performance" tests to not exceed UCHAR_MAX).

LOL -- I made the same mistake: "i < 0" for size_t will always be false... (what saves you is the i >= board.size() check)

LOL. I've very much written code like that :) (i.e. trying to emphasize some aspect and losing my follow code reviewers). Code clarity is Hard.

Ick -- this can use a ton of memory...

How the heck does this work??

Very clever! Also note you could early exit with 'false' in the loop if r ever goes negative.