Если уж быть занудой до конца, в строчке cin >> temp; происходит передача аргумента по ссылке в операторную функцию.

А к чему я это? А к тому, что ограничения наложены на код, который мы пишем сами, а не на то, что изначально написано.

Мне пришлось всё-таки признать, что он прав. Я посмотрел, оператор квадратных скобок ожидает указатель как один из операндов, поэтому в

arr[-42]

arr сначала будет преобразован в указатель, и только потом выполнится оператор [].

не должны. я встал в какую-то вершину. спустился из нее в правого сына и в левого. в правом внезапно нашел строку s и return-ул ее. но из левого сына я буду продолжать спускаться до листьев. другое дело, что было бы логично, если однажды в ходе программы функция fnd() уже облажалась, сразу все ее вызовы во всех местах из стека потереть.

Казалось бы, это давно известный факт, что обработка исключений дает огромный overhead.

Однако, бенчмарк (DFS на вырожденных в цепочку деревьях) выявил весьма интересную вещь: при размере цепочки до примерно 6500 версия с if-ом работает быстрее, на больших тестах она начинает проигрывать версии с исключениями. Видимо, причина в быстром сворачивании стека.

Я сейчас ради интереса напишу версии с setjmp/longjmp и с ручным сворачиванием стека.

UPD. Написал с setjmp/longjmp, обходит версию с if-ом начиная где-то с 22 вершин.

UPD2. Исходя из результата бенчмарка с setjmp/longjmp, писать ручное сворачивание стека уже как-то не хочется.

Ваше "простейшее решение" не является решением задачи, например, потому что приведённый вами выше "фрагмент кода из курсовой" не является корректным фрагментом кода на C++ (надеюсь, "после пяти курсов университета по специальности КН и СИИ" вы знаете, что в C++ нет конструкции "__asm {...}", это всего лишь фича майкрософтского компилятора?).

Не говоря уж о том, что в задаче в посте не были ни слова о 32битах или вообще о том, под какую платформу это будет собираться, так что самое нормальное решение — throw + try/catch.

Я не троллю, я не умею. Была сформулирована задача на "Я.п. с++". Было предложено решение в рамках этого языка (try/catch). Все нормально, симпатично.

Вдруг появляется "Вы наворотили тут просто горы всякой лишней ерунды", с предложением заценить какую-то догадку в ассембленом коде ("простейшее решение"). Причем, зависящее от платформы.

Мне не понравилось.

> А уж про другие нагромождения кода, написанные с нуля, вообще молчу, т.к. их авторы явно не читали условия полностью — где говорится, что в качестве шаблона должен быть взят заданный фрагмент кода и дописываться что-то должно только в теле имеющихся двух функций.

Если это про мой вариант — то весьма необоснованно. Я читал условие, но показал идею, а не конкретно то, что надо написать. Да, я заменил cin на sscanf, чтобы можно было продемонстрировать работу кода в codepad'е. И Добавил функцию, чтобы было понятнее, что происходит. Вот всё то же самое, но в точности в соответствии с требованиями:

#include <iostream>
#include <cstdio>

using namespace std;
 
void func1() {
  float temp;
  cin >> temp;
}
 
void func2() {
  float temp;
  func1();
  temp = [](){float temp; sscanf("", "%f", &temp); return temp;}();
  cout << temp;
}

int main() {
  func2();
  return 0;
}

Компилируется и работает в VS2012 в режиме Release. Кстати, в этом решении тип переменной по сути не важен.