Vitaly

Да. Читайте про статическую линковку.
Помимо этого, можно просто все нужные зависимости поставлять с исполняемым файлом.

rootObjects() возвращает только список объектов, которые были загружены с помощью load() или указаны в конструкторе QQmlApplicationEngine. Если вы ничего не загружали, то список будет пустым.
Чудес не бывает, если QList::operator[], говорит, что даже первого элемента нет, значит он пуст. Скорее всего там 0 элементов в отладчике. Если их не 0, но обращение к первому элементу вызывает assert, то там где-то выше может быть UB или память испортилась.

Зачем избавляться от strcpy? Она проста и эффективна, как и большая часть языка C. Проверка длинны строки на каждый символ или просто дополнительная проверка -- это проверка и, как следствие, затраченное время. При определённой культуре программирования, покрытия кода тестами (в том числе и со случайными данными), ревью, и использовании средств статического и динамического анализа, риски можно минимизировать. Взамен вы получаете быстрый и легкий код, практически без оверхеда. Из-за отсутствия оверхеда (тяжёлого рантайма), этот язык популярен для всяких системных вещей (я всё ещё скептически настроен насчёт Rust) + очень много кода на нём уже написано и его надо поддерживать + интерфейсы многих библиотек написаны на C из-за возможных проблем с ABI, в случае C++, например и т.п.
В C++ дела обстоят по-другому, и мешать (а тем более путать) его с C не стоит (ну только, если надо что-то системное дёрнуть в недрах вашего кода или написать обвязки для C библиотеки).

Я вижу несколько вариантов:
1) Заранее выделять/резервировать память в результирующем контейнере (resize()/reserve()). Можно просто где-то много памяти выделить и как буфер её использовать.
2) Использовать другую структуру данных для результата. Но тут должен быть баланс, возможно вы лишитесь преимущества кэш-линии, но быть может это будет не критично.
3) Можно просто в какой-то структуре хранить объекты, а потом собирать, когда достаточно накопится.

Возьмите книгу "Крэг Ларман. UML". Книга отличная, рекомендую и после экзамена целиком прочитать.

PS Рекомендую установить программу проверки орфографии.

То что создатели курсов подразумевают под основами программирования надо выяснять у них.
Рекомендую прочитать книгу Чарльз Петцольд Код + любой язык на базовом уровне. Этого должно хватить.

Вообще, если вам по какой-то причине необходимо преобразование вниз по иерархии классов, то это признак плохой архитектуры, т.к. неверно передаются зависимости или неверно выделены интерфейсы или вы как-то неправильно работаете с библиотекой. Хотя, конечно бывают и исключения, но их немного.

Почему бы просто не почитать документацию? Она даже на русском есть: https://git-scm.com/book/ru/v1/%D0%92%D0%B2%D0%B5%... . Сразу множество вопросов отпадёт. Ведь подобные вопросы зачастую от незнания истории и непонимания самой технологии.

Для начала следует научиться пользоваться поиском. Ответы на все ваши вопросы, кроме персонального, можно нагуглить за считанные минуты. Гуглить желательно на английском.
Пора уже привыкнуть, что до того момента, пока вы не наберёте определённый опыт (да и во многих случаях потом) ничего не будет работать с первого раза, а если и будет, то, не так как надо. Никто вообще не обязан вам предоставлять какую бы то ни было конкретику и т.п. Непонятно? Гуглите, читайте книги, собирайте материал из разных источников. Ещё раз, на вопросы вашего уровня уже давным-давно есть сотни ответов в интернете.

Попробуйте выставить: QT_LOGGING_TO_CONSOLE=1
Если не поможет, то скачайте инсталлер Qt с официального сайта и попробуйте ещё раз (можно без QT_LOGGING_TO_CONSOLE). Если заработает, то бага в сборке Qt для Ubuntu.

А они разве не поставляют компилятор под винду вместе с IDE? Под Линукс, например поставляют и компилятор, и отладчик, и даже cmake.

Да они есть. Например исключения не поддерживаются. Но ответ легко нагуглить.

В сообщении об ошибке UI в верхнем регистре, в коде, i в нижнем. Посмотрите, как сгенерирован файл ui_anotherwindow.h, там пространство имён должно совпадать с пространством имён из anotherwindow.h, ну и везде по коду.

Две последние буквы SOLID для вас ( https://en.wikipedia.org/wiki/SOLID_(object-orient... ). Вообще рекомендую прочитать всю эту статью, она очень дельная (+ все ссылки из секции Design and development principles). Использование этих принципов позволят писать относительно неплохой код даже без понимания (которое приходит с опытом обычно). Кстати, в этих статьях должны быть ссылки на книги по ОО-проектированию (ну в любом случае они неплохо гуглятся).
Необходимость в интерфейсах и абстрактных классах возникает в основном в больших коммерческих проектах. Использование интерфейсов позволяет понизить связанность компонентов системы (их уровень знания друг о друге), что, в свою очередь, позволяет легче модифицировать систему, работая в команде. Например пишет один программист какой-то класс для запуска задач и делает у него метод, который принимает интерфейс IRunnable (возможно с одним методом run()) и описывает контракт (правила, как метод run() должен себя вести). После этого, любому другому программисту достаточно будет реализовать интерфейс по контракту и он сможет пользоваться классом для запуска задач. При этом, класс для запуска задач вообще понятия не имеет о том что он запускает, ему важно знать, что это можно запустить, и любому другому классу нет необходимости знать, как его запускают, достаточно просто реализовать метод.

В CMake есть возможность использовать автоматический поиск zlib (если этот символ и правда оттуда) https://cmake.org/cmake/help/v3.10/module/FindZLIB.html .
Или добавьте ваш флаг к флагам линкера.

Детальных инструкций не даю, а то ещё гуглить разучитесь. Нуб не нуб -- это не оправдание.