Wataru

У стратегий можно сделать статические методы. Например, метод, возвращающий имя, и метод, создающий экземпляр класса.

В вектор/мап кладите пары stragetyX.GetName(), &stategyX.CreateStrategy
А дальше находите там нужную строку и вызывайте функцию-фабрику.

Но вообще, такие штуки c хранением функций-фабрик в контейнере редко делают. Можно в одном месте и иметь вереницу из if-else. Будет не одна длинная строчка на каждый новый класс, а две но покороче.

void Field(vector <Circle> &circles, vector <Rectangle> &rects) {

Это передача по ссылке а не через указатель. Сюда надо передавать сам circleArray.

Но сразу скажу, препод такой подход не примет. Вся идея полиморфизма, наследования и виртальных методов в том, чтобы хранить везде указатели на Figure. А то, что какие-то из них на самом деле Circle, а какие-то Rectangle, это уже детали реализации. Виртуальные методы должны переопределятся в потомках и именно там должна быть логика, специфичная для разных фигур.

Например, у фигур может быть метод "выведи себя". Тогда в коде работы с фигурами вы просто вызываете этот метод у васех фигур даже не зная, круг это или прямоугольник. А вот перегруженный вертуальный метод уже будет выводить конкретную фигуру.

И ваш массив geometry в родительском классе смысла не имеет. Потому что он же не знает, что с этой геометрией делать. Там могут быть углы прямоугольника, а может быть центр круга. Вам надо в каждом классе потомке тупо хранить данные о нем (центр круга и радиус, например)

double circleMainArray[circArraySize] = { centerCoordX, centerCoordY, radius };
geometry = circleMainArray;

Тут вы заводите локальную переменную circleMainArray, а потом копируете ее адрес в член geometry. По выходу из конструктора локальная переменная удаляется. На ее месте потом поялвяется что-то другое (она на стеке, так что там могут быть адреса возврата, значения регистров или других локальных переменных).

Правильно было бы выделять память в куче под geometry и или заполнять его руками, или копировать туда данные из локальной перменной. А еще лучше - использовать std::vector.

geometry = new double[circArraySize];
geometry[0] = ...;
geometry[1] = ...;

Или лучше

std::vector<double> geometry;
...
Circle(double centerCoordX, double centerCoordY, double radius) :
   geometry{centerCoordX, centerCoordY, radius} {}

Проблема в том, что код функций из шаблонов генерируется по мере надобности.
Вот встретил компилятор где-то Test<int> - и начинает создавать функцию для int.
Но в единице трансляции с Functions.cpp он этого не встретил и ничего не генерирует. А когда он компилирует Source.cpp он может только сгенерировать декларацию, но не определение функции. Ведь он видит хедер, но не что написано в Functions.cpp.

Поэтому, если весь шаблон определять в .h файле то компилятор сможет сгенерировать что ему надо всегда.

Второй варинат решения проблемы - в Functions.cpp указать компилятору, что шаблон будет использоватся с такиим-то типами:
using Test<int>;

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

Обычно минусы тут перевешивают плюсы и шаблоны всегда целиком пишут в хедерах. Но это не единственный враиант. Неправда, что шаблоны должны целиком находится в хедерах.

Так.

Правильно - вот так:
object = new Kvadrat();

Теоретически, можно было бы делать как вы пытаетесь:
object = &kv;

Но конкретно в вашем коде - это будет UB, потому что kv - это локальная переменная и у нее очень огранниченная область видимости - внутри if. И вот за пределеами этого if, где вы и попытаетесь, очевидно, использовать указатель object, эта локальная переменная будет уже уничтожена. У вас будет т.н. висячий указатель - указывающий туда, где данные были, а сейчас там может быть все, что угодно.

Поэтому, если вы присваиваете указателю адрес какого-то объекта (&) вам надо убедиться, что время его жизни не меньше, чем у указателя, пока вы будете его использовать. Можно, например, сделать переменную глобальной, но это очень плохой код. Лучше завести все 4 разных класса в начале функции, потом прочитать нужный и взять указатель на него. Этот подход иногда даже используется на практике.

Но лучше, все-таки, не плодить лишних сущностей и создавать объект сразу в куче с помощью new. Тогда он сам нигде не уничтожится.

Это проблема работы с памятью. Вы там освобождаете память из-под str перед тем, как попросить gmp заполнить эту строку данными:

free(str);
mpz_get_str (str,10 , mul);

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

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

В документации есть пример:

std::thread t5(&foo::bar, &f); // t5 runs foo::bar() on object f

У вас надо cделать: std::thread t5(&A::Zoom, this);

Во-первых, я бы с помощью бора все урлы перенумеровал. Теперь в задаче есть 400,000 ключевых слов, связанных с 10-ю числами.

Далее, В каждой группе по 10 чисел есть 10!/4!/6! = 840 четверок. Всего различных четверок наберется 840*400000 ~= 330,000,000. Это не так много. Для хранения всей этой радости, правда, понадобится ~8 гигабайт памяти, но это подъемно. Потом вам надо среди этих 300 миллионов найти совпадающие. Можно отсортировать (лучше радиксом) или воспользоваться хеш таблицей (правда тут еще больше памяти потребуется).

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

"E" (это вообще-то сигма из греческого алфавита) - знак суммы. выражение справа надо просуммировать, подставив вместо k все числа от 3 до n. П - это знак произведения. Выражение справа надо перемножить для всех указанных значений i.

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

Ваше решение в вопросе почти правильное. Проблема только в том, что вам надо подсчитать что-то вроде c1*a1*a2*a3 + c2*b1*b2*b3. А вы используете одну и ту же переменную для подсчета каждого слагаемого и общей суммы. У вас получается что-то вроде (c1*a1*a2*a3+c2)*b1*b2*b3

Судя по всему, это число вылезло в результате эксперементов каких-то исследователей. Они просто попробовали кучу разных факторов и нашли что при 1.247 вроде как быстрее в среднем. Формулу по это число потом какой-то шутник придумал. Кроме как в русской википедии (без ссылки на источник) я нигде эту формулу найти не могу.

Влияет оно так: если число слишком большое, то мелкие элементы в конце массива не успевают перехать в начало на итерациях с достаточно большим шагом; если же число слишком мелкое, то делается много лишних итераций.