Wataru

Потому что тут разное поведение.

Первый вариант отбрасывает дробные части от копеек, а второй отбрасывает дробные части от рублей. Ведь при делении на 100 в целых числах идет округление вниз. Если брать p процентов с округлением вниз от числа в рублях, то и получится целое число в рублях. Если брать от числа в копейках, то и получится целое число в копейках.

Поскольку второй код отбрасывает все копейки при прибавлении, то ему требуется больше итераций, чтобы дойти до y. На самом деле он может даже виснуть, если там получается прибавление 0.

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

В компьютерах используется дискретное преобразование, потому что ну не могут компьютеры работать с бесконечным неприрывным объектом, коим является функция.

И да, там результат - это массив комплексных чисел, поэтому выходные данные в 2 раза больше входных, которые являются вещественными.

Сообщение говорит, что было брошено исключение, которое никто не поймал и поэтому программа завершилась.

Обрабатывайте исключения (конструкция try..catch) где-нибудь в main, тогда можно будет вывести сообщение с ним связанное. Может станет понятнее, откуда оно было брошено. Или можно просто пискать в коде "throw" - скорее всего оно и срабатывает.

Надо смотреть, что там get_childrens возвращает. Судя по ошибке, там где-то замешаны unique_ptr, которые нельзя просто копировать.

Подозреваю, что ошибка исправится, если в for сделать item ссылкой.

Число q, судя по тексту, уже дано вам в файле.
Поэтому просто циклом q раз читайте команду.
Там читайте одно число, и если это 1, то читайте i, x. Если это 2 - то читайте k.

for (int line = 0; line < q; ++line) {
  cin >> command;
  if (command == 1) {
    int i, x;
    cin >> i >> x;
    UpdateValue(i, x);
  } else {
    int k;
    cin >> k;
    ShiftRight(k);
  }
}

1) (Вкусовщина) стиль наименования не самый удачный. И переменные и функции называются одинаково - каждое слово с большой буквы без разделителей. Во всех массово применяемых стилях обычно переменные, функции и константы называются по разному. Например, переменные можно называть log_password. Функции и так оставить с большой буквы, а константы - полностью большими буквами.

2) обилие вложенных if. Практикуйте ранний выход. Например в Login() можно сделать так:

if (Data.is_open()) {
  std::cout << "Ошибка. У вас нет аккаунта" << std::endl;
  return;
}

И весь оставшийся код оказывается на 1 уровень выше.

3) Бесконечные рекурсивные вызовы - это плохо. Рано или поздно программа упадет с закончившимся стеком.
У вас Menu вызывает Login, который опять вызывает Menu. Да и сам Menu тоже.

Лучше сделать в Menu бесконечный цикл (while(true)) и или выходить из программы через exit(), или возвращать из Login, что надо завершаться и тогда в Menu делать break.

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

Используется для этих вещей:
1) Можно иметь "циклические зависимости". Например, функция использует класс, а класс использует функцию. Или два класса используют друг друга. В каком порядке их определять в файле? Так уж повелось, что компилятору надо как-то знать о всех используемых в коде штуках до их использования (в основном). Возможность отдельно объявить функцию/класс как раз решает эту проблему. Можно было бы переделать весь компилятор, чтобы он сначала по всему файлу искал функции, но по каким-то, возможно веским, причинам это не было сделано еще в Си. А C++ потащил и это с собой.

2) Разделение программы на "модули" или библиотеки. Этот ужасный, устаревший и неудобный механизм include-ов позволяет разбить программу на хедеры и файлы с реализацией. Потом хедеры только с объявлениями включаются в другие файлы, чтобы компилятор знал о коде в других модулях, а реализация собирается в отдельный объектный файл. В конце линкер собирает все объектные файлы в исполняемый файл и/или библиотеки. Если бы объявления и определения не были разделены, то весь код в проекте компилировался бы кучу раз в каждом объектном модуле. Это просто глупо.

3) И вообще - это красиво. Иметь где-то аккуратный список всех методов класса (или функций в библиотеке) удобно, когда вам надо разобраться, а что этот класс делает и как его использовать. Если бы там еще и код методов был, то это было бы сложнее читать.

У вас в set хранятся указатели на char. В set они сравниваются как указатели. Как значения адресов. Strcmp же смотрит на содержимое памяти, на которую указатели ссылаются. Поэтому имея в памяти две совпадающие строки вы получите вот это вот - указатели не равны, а strcmp - равно.

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

Одна очевидная ошибка - вы не уменьшаете n при удалении элемента. И тогда на следующей итерации вы будете что-то делать с элементом за концом массива.

Еще одна ошибка у вас в том, что вы в add, например, всегда удаляете указатель на f. А в самом начале этот указатель неинициализирован. Удаление такого случайного указателя - это undefined behavior. Программа может упасть сразу, а может только на следующей итерации цикла.

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

Проще "отсортировать" заданные координаты. Если x1 > x2, поменяйте их местами. То же с z1 и z2, А потом остается только первый случай в вашем коде.

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

Константа вылезает из деталей реализации операций. Вот сортировка пузырьком делает ровно n(n-1)/2 сравнения и помен в худшем случае. Еще столько же операций инкремента счетчика индекса, столько же проверок на конец цикла. Плюс еще n операций для внешнего цикла. И все это O(n^2). Хотя там есть есть /2 и операций четыре типа. И они еще разное время занимают. Скажем, проверки занимают 10 тактов, а инкрименты - 1. Но вся эта мишура не влияет на скорость роста и прячется в константе. Если все сложить. То будет C*n^2 +C2*n+C3 тактов на алгоритм.

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

Можно из одного уравнения выразить y через x, подставить в другое, найти x, потом найти y.

Или можно получить эти формулы в одно действие методом Крамера.

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

Правильнее добавить в тестируемую функцию какую-то работу. Тогда вы будуте действительно сравнивать вызов функции и метода. Или отключить всю оптимизацию.