Wataru

Много ошибок:
1) number[i - 3] == 8; number[i - 2] == 8;, вопреки вашим ожиданиям, не присвоит значения в массиве значению 8. Тут выполняются 2 сравнения с 8, результат которых игнорируется.

2) Неинициализированные переменные. В частности, k, из-за чего происходит выход за границы массива.
Плюс, если x изначально окажется 3 (а она тоже не инициализирована), то после первой же 8 вы как бы найдете вхождение и тоже будете выходить за границы массива.

Никак. Смотрите на (2).

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

В вектор/мап кладите пары 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. Тогда он сам нигде не уничтожится.

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

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

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

Открывайте файл через ifstream (или wifstream).
Вот эту вот штуку и передавайте вместо wcin.

Это просто 64 битный (обычно) тип. Сейчас процессоры умеют работать с такими числами напрямую, без "склеивания" двух 32 битных чисел.