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

Вот отличная книга: C++ Templates: The Complete Guide (2nd Edition) 2n.... Она выгодно отличается тем, что покрывает даже 17ый стандарт.

>За последние три месяца мне удалось освоить Python
не удалось

>Разобрался с гит
не разобрались

>линуксом на уровне пользователя
не разобрались

>Lua
не разобрались

Для начала приземлитесь. За 3 месяца вы ни в чём из этого разобраться на хорошем уровне не могли.

>Где писать игры для портфолио
Это делать не обязательно. Это, конечно, плюс, но не такой существенный чтобы прямо быть обязательным.

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

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

А так, чтобы попась в геймдев достаточно просто навыков программирования и хорошей теоретической базы (графы, математика), демки не обязательны.

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

using namespace std;
class Student
{ 
public:
    string name; 
    string last_name; 
    string year;
    string get() 
    { 
         string s =  name + ',' + last_name + ',' + year;
         return s;
    }
};

int main(int argc, char* argv[])
{
    Student student;
    student.name="Ivan";
    student.last_name="Ivanov";
    student.year = "2001";

    vector<Student> v1;
    v1.push_back(student);
    cout << v1[0].get();
}

Потому, что это запрещено стандартом. Укажите размер массива или используйте std::array.
Советую добавить следующие флаги компиляции: -pedantic -Wall -Wextra.

Ну, как минимум, вы можете просто выполнить bash

git add .
git commit -m '${env.BUILD_NUMBER}'
git push origin ${env.target_branch}

У вас pipeline?

Значит так, берем толстую тетрадь, ручку и пишем фразу "Статические методы не имеют отношения к ООП" до тех пор, пока не запомним это на всю жизнь.
Суть объектно ориентированного программирование, как понятно из названия, заключается в том, что должен существовать объект. Статика существует не в контексте объекта, а в контексте класса! Из этого вытекает то, что на протяжении всего жизненного цикла вашего кода будет существовать лишь одно глобальное состояние статических членов класса.

Использовать статику нужно в случае, если то, что вы ей описываете принадлежит всей группе объектов, а не одному. Например, у класса Human может быть статический метод numberOfLegs(), который возвращает количество ног у людей. Количество ног - это общее свойство для всех людей (Речь идет о здоровых людях). В данном случае можно было использовать константу класса, но это не так важно, ведь, по сути, константа - это тоже статический контекст. А вот имя - это уже свойство каждого отдельного человека. И очень важно чтобы статические методы не изменяли состояние системы в целом, не содержали побочных эффектов.
В статические методы можно выносить какую либо служебную логику. Например, метод перевода числа из арабской в римскую запись следует сделать статическим.

Есть ли у статического варианта какие-то подводные камни

Большое количество. При чем, не таких уж и подводных. Из-за того, что статика глобальна, она плохо поддается тестированию, ее нельзя замокать. Глобальное состояние плохо поддается отладке. Отсутствует возможность подменить реализацию, так как это позволяют сделать объекты.

Ну, раз хочется - бери.

В С++ нужно отдельно реализовывать конструктор потомка

class Base {
    public:
    Base(int _i): i(_i) {//блок инициализации
    }
    private: 
    int i;
}

class Derived : public Base {
    public:
    Derived(int _i): Base(_i) { //зовём super конструктор
    }
}

void* используется как указатель на сырые байтовые данные, не имеющие конкретного типа.
Обычно это используется…
1. В чтении-записи в файлы и на устройства, когда мы можем писать туда абсолютно любые типы.
2. В «многоликих» функциях, которые могут принимать данные разных типов (malloc/calloc, часть функций WinAPI и ODBC).
3. Как дескриптор — указатель, который запрещается разыменовывать. В Си для этого также часто используют указатель на недоопределённый тип, в Паскале с другими правилами эквивалентности типов — на пустой record. Но только пока не появится очередная многоликая функция вроде CloseHandle.
4. Для обеспечения т.н. замыкания — передачи callback’у контекста, откуда была вызвана функция, вызвавшая callback.

BOOL WINAPI EnumWindows(
  _In_ WNDENUMPROC lpEnumFunc,
  _In_ LPARAM      lParam
);

BOOL CALLBACK EnumWindowsProc(
  _In_ HWND   hwnd,
  _In_ LPARAM lParam
);

Вот этот LPARAM, который обычно определяется как какой-то указатель, и есть замыкание. Функция EnumWindows обещает передать его в функцию lpEnumFunc без изменений.
(В Си++ для этого также используют виртуальные интерфейсы, но такой метод, сами понимаете, языкозависим и не годится для межъязыкового API.)

Что происходит на стороне функции? Одно из двух (считаем, функция написана на ЯВУ).
1. Либо вызывается некая функция устройства, которая говорит: «записать 100 байт», и дальше уже работает железо.
2. Либо мы преобразуем void* в нужный нам тип и работаем с ним.

Типы указателям дают по трём причинам.
1. Вы забыли про операцию «разыменовать указатель». Чтобы его разыменовать, он должен иметь тип!
2. Чтобы не ошибаться и не переприсвоить несовместимые указатели.
3. Для полиморфизма — в Си++, давая delete x, мы даже можем не хранить, сколько байтов в блоке, поскольку мы знаем длину типа. (Есть ещё и виртуальные классы, но это другой вопрос.)

Если объяснить очень-очень по-простому и не вдаваться в тонкости, то дело обстоит так: DLL, которые содержат исполняемые функции, методы и прочее действительно должны быть загружены в адресное пространство, которое представляет собой некий буфер, он выделяется из объема оперативной памяти и этот буфер принадлежит только этому процессу, т.е. тому процессу, в котором выполняется приложение. Физическая память к этому диалогу между приложением и DLL не имеет никакого отношения... это если кратко и без фанатизма.