(Я предполагаю, что это просто какое-то упражнение на мысль или даже уловка с домашним заданием / интервью, но я полагаю, я мог бы представить какой-то странный сценарий, когда вам по какой-то причине не дают места в куче действительно плохой пользовательский менеджер памяти? какие-то странные проблемы времени выполнения / ОС?], пока у вас все еще есть доступ к стеку ...)
Обход в ширину традиционно использует очередь, а не стек. Природа очереди и стека в значительной степени противоположна, поэтому попытка использовать стек вызовов (который является стеком, отсюда и название) в качестве вспомогательного хранилища (очереди) в значительной степени обречен на неудачу, если вы не делаете что-то глупо смешное со стеком вызовов, которым ты не должен быть
В том же ключе природа любой нехвостовой рекурсии, которую вы пытаетесь реализовать, заключается в добавлении стека в алгоритм. Это больше не позволяет выполнять поиск в двоичном дереве в ширину, и, таким образом, время выполнения и все такое для традиционной BFS больше не применяется полностью. Конечно, вы всегда можете легко превратить любой цикл в рекурсивный вызов, но это не какая-либо значимая рекурсия.
Однако, как продемонстрировали другие, есть способы реализовать что-то, что следует семантике BFS за определенную плату. Если стоимость сравнения стоит дорого, но обход узлов обходится дешево, то, как @ Simon Buchan , вы можете просто запустить итеративный поиск в глубину, только обработав листья. Это будет означать отсутствие растущей очереди, хранящейся в куче, только локальную переменную глубины и многократное наращивание стеков в стеке вызовов при повторном обходе дерева. И, как отмечал @ Patrick , двоичное дерево, поддерживаемое массивом, в любом случае обычно хранится в порядке обхода в ширину, поэтому поиск в ширину в этом случае будет тривиальным, также без необходимости во вспомогательной очереди.