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

Любая потеря фокуса приложения это 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 не имеет никакого отношения... это если кратко и без фанатизма.

Не используйте нормализованный вектор,- ну его!
Оттягиванием - запомните позицию когда нажали мышь, отнимите эту позицию от позиции когда отпустили мышь,- и все, вот ваш вектор ;)