Wataru

mergeSort(a, temp, 0, mid);

Надо сортировать часть с lo по mid. А не с 0.

В общем случае тут нужен бинарный поиск. Задаете вашу таблицу в виде двух массивов. Первый - значения которые вы ищете, второй - ответы для них. Отсортированные по первому массиву.

Бинарным поиском находите в первом массиве индекс значения и выдаете ответ из второго массива по тому же индексу.

Подкручивая бинарный поиск можно округлять искомое значение до табличного вверх или вниз.

Если обратная нотация, то знак ± должен, как и бинарные операции, идти после операндов. Тогда -(-1 + 2) становится 1 ± 2 + ±. По ± надо менять знак числа на верхушке стека.

Соответственно в парсере, если видите унарный минус перед скобками, то переводите скобки в нотацию, а потом дописываете ±.

В С++ есть codecvt для конфертации между кодировками.

С помощью его можно читать файлы в utf_8, например, так:

std::ifstream f("file.txt");
std::wbuffer_convert<std::codecvt_utf8<wchar_t>> conv(f.rdbuf());
std::wistream wf(&conv);

Потом читаете из wistream, как будто это обычный cin. Только вместо char нужен wchar_t, а вместо string - wstring.

file.get() читает один символ, возвращает его и переходит к следующему символу ввода. Поэтому код:

while (file.get() != ']')
{
   temp += file.get();
}

читает первый символ, сравнивает со скобкой, потом приписывает в temp второй символ. Потом читает третий и, возможно, приписывает четвертый и т.д. Два вызова file.get() выполняют два чтения.

Правильно делать так:

while ( (с = file.get()) != ']')
{
   temp += с;
}

И похожим образом обрабатывайте '[' перед этим. Читайте в переменную, сравнивайте и не забудьте прочтенный символ засунуть в строку.

Ну, или используйте в условиях istream::peek.

В достаточно большом проекте - это просто невозможно. Ни один человек в мире не может понимать целиком, например, хром.

Если проект нормально структурирован, то все разработчики должны понимать примерно чем занимается каждая часть и общую архитектуру.

Но иметь белые пятна - это нормально, если непонятной частью занимаются другие разработчики, естественно. Свой кусок знать надо целиком.

Ну, раз обход в глубину нужен, то запускайте от каждой вершины полный перебор и ищите пути назад в эту же вершину.

Для этого вам надо будет помечать вершины при входе, как пройденные, и убирать пометку при выходе. В самом обходе перебирайте все ребра и рекурсивно запускайтесь от пока не обойденных вершин. Если видите ребро в первую вершину - вы нашли цикл, сохраните текущую глубину в ответ, если она лучше пока что найденного.

Для ускорения можно: Не уходить рекурсивно глубже, чем текущий ответ. Помечать вершины не просто пометкой посещена/не посещена, а глубиной рекурсивного вызова. Тогда, если есть ребро в уже обойденную вершину - вы нашли какой-то цикл с какой-то длинной (текущая глубина - глубина второй вершины + 1). Его сразу же можно брать как возможный ответ. Если граф связный, то можно запускаться только от одной вершины, или можно запускаться от одной вершины в каждой компоненте связности.

Но это все равно будет работать за экспоненциальную сложность.

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

Сортируют параллельно куски массива. В конце объединяют отсортированные части операцией слияния (эта часть не параллельна).

Надо сказать, реализация ужасна. Последняя часть - слияние, похоже, вообще выполняется за квадрат. Т.е. этот подход сильно медленнее непараллельной сортировки всегда.

Если уж и параллелить radix sort, то надо параллельно считать сколько в каждом куске каждой цифры, потом высчитать, куда каждая цифра из каждого куска должна попасть, и потом параллельно каждый кусок перетасовать в нужные места.

Почитайте про Name mangling

Эти заковыристые имена создает компилятор. Если заставить его это не делать, то все сломается. Поэтому, кажется, вы всегда будете получать вот такие вот странные имена. Но их можно расшифровать назад (или вот).