Vitaly

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

Проще говоря, допустим случай, когда вам надо отсортировать массив. Зная, что в STL есть и класс для массива и методы сортировки, вы идёте и читаете документацию, а потом используете. cppreference -- отличный ресурс с примерами.

Я помню читал одну относительно тоненькую книгу по STL когда-то. Вроде бы неплохая была. Сейчас уже наверно устарела: "STL tutorial and reference guide" by David R. Musser .

Дело тут ещё и в методах измерения. По-хорошему, нужно взять любой тестовый фреймворк, будь-то google benchmark или там catch2, который позволяет осуществлять замеры производительности. В нём создать два бенчмарка и смотреть на разницу. Если она будет какая-то существенная, то брать профилировщик, правильно компилировать проект и смотреть что занимает больше всего времени выполнения.
А уже после этого можно играть с флагами и смотреть какой код генерируется в обоих случаях. Можно и до в этом конкретном случае.

И вот тогда вы сможете ответить на вопрос почему на вашем компьютере что-то работает медленнее или быстрее. А потому можно ещё и обнаружить, что для разных архитектур и/или компиляторов будет генерироваться разный код, будут применяться разные оптимизации и производительность может отличаться.

PS
Но у вас скорее всего и правда оптимизатор код выкидывает в первом случае всё считается во время компиляции, а функция встраивается. Во втором случае это сложнее.
Вот тут ещё можете посмотреть какой код генерируется и с флагами поиграться: https://www.godbolt.org/

Вам надо сделать следующее:
- Создать проект в вашей IDE (VisualStudio), на основе CMake (предпочтительно) или MSBuild
- Посмотреть как реализована интеграция с пакетным менеджером vcpkg
- Добавить в список зависимостей vcpkg libcurl

После этих простых шагов (по каждому из которых много документации в открытом доступе), всё у вас заработает. Точно так же можно получать другие полезные зависимости с помощью vcpkg.
Это и будет современным и переносимым подходом к разработке и управлению зависимостями.

Вот тут есть примеры сигнатуры функции: https://en.cppreference.com/w/cpp/io/basic_ostream...

basic_ostream& operator<<(
    std::basic_ostream<CharT,Traits>& (*func)(std::basic_ostream<CharT,Traits>&) );

Есть замечательная функциональность: https://en.cppreference.com/w/cpp/utility/source_l...
Доступна начиная с C++20. Буду образовывать заодно и местных экспертов :)
Ну или макросы.

Разницы нет. Так как и в первом и во втором случае самая ресурсоемкая операция выполняется один раз. Во втором случае, проверку разумеется никакой оптимизатор не выбросит, но она 1) работает за константу и 2) практически не влияет за счёт branch prediction.
Есть случаи, когда невозможно (неудобно) использовать resize, есть, когда reserve. Для 99% случаев подходы идентичны.

Если вы используете класс QImage, то в официальной документации написано, какие строки надо добавить в CMakeLists.txt (https://doc.qt.io/qt-6/qimage.html):

find_package(Qt6 COMPONENTS Gui REQUIRED)
target_link_libraries(mytarget PRIVATE Qt6::Gui)

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

Касательно кода, вам как минимум надо вызывать event->accept() и к слотам func_1/2 присоединяться с аргументом Qt::QueuedConnection (а не вызывать их напрямую вроде obj->foo()). Тогда и мьютекс не понадобится.
Касательно объекта типа QPainter, его лучше создавать в обработчике события, как и рекомендуется в официальной документации.

На вопрос же "почему оно случайно падает?" ответить просто невозможно, не имея как минимум полного кода приложения, параметров компиляции, запуска и знаний об операционной системе. После этого надо собрать Qt в отладочном режиме, собрать с ним приложение и смотреть потоки в отладчике и их состояние. Но я не уверен, что это всё необходимо, принимая во внимание первый абзац. Строго говоря, проблема может быть совсем не в том участке кода, который вы привели, да и код может быть совсем другой надо написать. Очень мало данных.

Рекомендую использовать vcpkg (можно и conan) или же docker-контейнер с нужными зависимостями для сборки. Сам генератор систем сборки CMake.

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

При необходимости могу подробнее расписать достоинства и недостатки.