Итак, кто из олдскула помнит игрушку "Frogger", где надо было перепрыгнуть дорогу и реку и не попасть под машину или в пасть крокодилу и не утонуть, тому будет проще понять условие.
На вход дан упорядоченный список с позициями камней, расположенных вдоль оси (т.е. у них одна координата). Первый камень имеет позицию 0, второй - 1 (есть тесты, где это не так, и тогда надо возвращать неудачу).
Лягушка прыгает сначала на 1 позицию (с камня 0 на камень 1), а дальше она может прыгнуть на k - 1, k или k + 1 позиций, где k - длина её предыдущего прыжка (у неё есть инерция, и как видно из тестовых данных, лягушка может развивать космические скорости). Камней - не более 2000 шт, номера позиций - от 0 до INT_MAX.
Нужно вернуть true, если лягушка сможет доскакать до последнего камня, и false - если не сможет.
Уровень Hard. Полный текст задачи тут:
https://leetcode.com/problems/frog-jump/description/
Один из коварных тест кейсов полностью не может быть приведёт в силу объёма, поэтому выложен тут:
https://pastebin.com/BjBDigaf
Видим, что лягуха достигает последнего камня со скоростью, в 999 раз превышающей её начальную скорость. Это не снилось и сверхзвуковому истребителю, если принять скорость в начальном прыжке за 1 м/с.
"А я знаю, а я знаю, тут надо применять динамическое программирование" - скажет прошаренный алгоритмист... и получит от 80 до 1000+ ms execution time и чудовищный перерасход памяти, заняв почётное место в клубе посредственностей (82%) или лузеров (7%). Но мы же не хотим там оказаться, правда?
Поэтому основная проблема заключается в том, чтобы попасть в топ по времени выполнения и памяти. Например, с такими результатами:

Добавлю, что топовое решение - несколько неожиданное, и на первый взгляд выглядит, как экспонента. Но за счёт быстрого отсечения ненужных ветвей оно близко к линейному.
Я сделал аналогичный перебор, но вместо рекурсии - свой стек на векторе с преаллокацией, и получил 8 мс и 100% уделанных. По памяти - тоже 100% уделанных, 10.96 Мб. Причём, с первой отправки.
Тогда они, по ходу, обиделись, и начали задротить повторную отправку своих решений, пока не получили 5мс и не знаю, сколько по памяти, но чуть меньше, чем у меня.
Массив посещений не нужен, ухудшает производительность. Необходимость предварительной оценки тоже сомнительна.
Вызов функции: 1 указатель фрейма, 1 указатель IP для возврата, 1 указатель this, 1 64-битная пара, итого 4 двойных слова (если компилятор не генерит передачу ещё чего-нибудь).
Пуш в свой стек: 1 64-битная пара.
Сам вектор стоит 3 указателя, но это константа.
Я и обычных-то вызовов функций внутри циклов стараюсь избегать, __attribute__((always_inline)). А некоторые и этому не доверяют, инлайнят руками или через препроцессор, как в старом добром Си. В топе всякого насмотришься. :-)