Евгений Шатунов

Это получается не переопределение, а просто метод у другого типа с таким же названием. Изначальный метод все еще можно вызвать у объекта класса (если привести тип). Также изначальный меотд доступен внутри класса потомка.

Суть переопределения в том, что это ПЕРЕопределение. Замена одной функциональности на другую. Без virtual этого не происходит.

Можно же объявить функцию fn у двух совсем не связанных классов, вызвать ее у двух экземпляров и увидеть разный результат, правда? Но тут нет никакого переопределения. Концептуально у вас тут то же самое.

Ну у вас main() дважды объявлена, так делать нельзя.

Кроме параметров функции, можно возвращать структуру с именованными значениями или std::vector или std::touple.

Насколько мне известно...
Статический массив:
- Размер должен быть известен на момент компиляции. Твой пример - это нестандартная фишка ряда компиляторов, по-хорошему для статического массива размер не должен быть динамическим (определяться во время выполнения).
+ Компилятор сам позаботится об удалении массива.

Динамический массив:
+ Размер может определяться во время выполнения.
- Нужно не забыть освободить память массива самостоятельно.

А вообще, если нет причин делать иначе, используй std::vector. Если тебе понадобится именно массив в стиле C, вектор позволяет его легко получить методом .data().
+ Размер не просто динамический, вектор может переаллоцировать свою память по мере надобности. Так что для ситуаций, когда размер заведомо неизвестен, вектор весьма удобен.
+ Вектор сам управляет своей памятью. Убил вектор - убил управляемый им массив.

dlib максимум 3.6 Python поддерживает.
Думаю, правильно будет создать виртуальное окружение (например virtualenv), pycharm это делает особенно удобно; и в нем поставить нужную версию python и остальные нужные библиотеки ставить там же. И там же писать код.

Также со слов Евгений Шатунов надо убедиться, что

должна стоять нагрузка на разработку C++ приложений с использованием cmake.

- как я понял, как раз об этом писали в большом транспаранте в traceback.

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

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

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

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

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

Проблема в том, что код функций из шаблонов генерируется по мере надобности.
Вот встретил компилятор где-то 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);

1. Найти работу до достижения 18-и лет почти нереально.
   
2. Найти первую работу разработчиком очень тяжело.
   
3. Найти работу в геймдеве, не имея опыта разработчика, почти нереально.
   
4. Найти работу с GameMaker почти нереально.
   

В вашем случае наложение всех этих факторов многократно умножает сложность задачи.