Don't undertand your logic. How iterator type depends on position of smallest in array?

In C++ and, as I see in comments, some other languages happens critical difference between w / (h * h) and w / h / h due to float point calculation specificity. While both are legit solutions.

Generally, good practice in this case when testing float point numbers is to allow some less precision than provides FP types of language. f.e. 0.0001

Look at begining of your function. Empty array is {}

{{}} - array containing 1 empty array.

;)

I can prepare a fork with a fix if you want

I've already solved it anyway. But sure forthcoming users will appreciate your work.

I can prepare a fork with a fix if you want, but I need some time.

using namespace std; is not needed, and in case of this particular C++ translation it actually breaks things. There are some includes missing here and there in the translation, and the problem is that using namespace std; seems to be necessary in solution (but it's not) because it is missing in another place (specifically, in tests).

This is a valid issue, and code of snippets should be corrected: missing includes should be added, and usings should be added where necessary, and removed where unnecessary.

The "Setup" solution has "using namespace std;". Maybe it is not the best way but it is there and is needed.

C++ - does not work when removed using namespace std

Which is better than brute force O(n^2)

Not so easy. long long type have a limited size and hence n won't be too big. Also in "brute force" method you can make cheap iteration, especially by avoiding insert and erase string functions.

Numeration from 1 is bad idea, because formulas for faster calculation requires numeration from 0

Why not? Me, and as I see, some people in comments stumble at this point.

So I guess it would be good to warn about this moment. And - if possibe - to upgrade test ceses.

Not a kata suggestion!