В деструкторе MainWindow вместо player->deleteLater() нужно написать delete player. А лучше изменить тип player на std::unique_ptr<QMediaPlayer>, тогда и delete делать не придётся.

Среди других идей (добавить Custom Process Step, чтобы при сборке использовались другие переменные; определять родительский процесс) была изначально самая простая и очевидная, что уже есть какая-то переменная, которая определена при запуске в QtCreator. Только как она может называться и как её искать - х.з. . Решил ткнуть в самое простое: добавил message($$CONFIG) и посмотрел, что выводится при загрузке проекта в QtCreator и при сборке. Там эта qtc_run и засветилась, долго искать не пришлось . Хотя добавить её в документацию не помешало бы.

"Другие пользователи" - это святое, нельзя допускать, чтобы они напрягались, особенно по всяким мелочам . Хотят "из коробки"? А пожалуйста!:
Qmake: Add special CONFIG variable "qtc_run" when parsing project files.

Тогда можно попробовать сделать так: в зависимости от каких-то внешних условий включать или отключать определённые части в .pro файлах. Внешним условием может быть определение/не определение переменной, которая передаётся параметром командной строки при вызове qmake. В QtCreator в Projects/Build Settings  создать отдельную build configurartion для "лёгкой" версии проекта, в Build Steps/Additional arguments передать определение переменной, например "SKIP_EXTRA_PHASE=TRUE". А в .pro файлах проверять, определена заданная переменная или нет, и, в зависимости от этого, что-то делать или не делать .

Если эти "ненужные" части закомментировать в .pro файле, проект будет нормально загружаться в QtCreator?

Есть, но особых восторгов о ней не слышал. Чтобы бросить Qt и перейти на wxWidgets. Хотя может с такими телодвижениями The Qt Company часть сообщества перетечёт на wxWidgets, от греха подальше, и она похорошеет .

Все хотят денег, сотрудники The Qt Company не исключение, а её акционеры и подавно . Тем более, что конкурентов с достойным кроссплатформенным GUI фреймворком на C++ не видать. Или есть?

Утилиты типа Process Hacker много интересного о процессах выдают. В том числе список модулей.

Никто за Вас не напишет дерево с нужными Вам характеристиками. Выше предлагали два варианта, которыми люди пользуются. И Вы ими воспользуйтесь, или опишите, что Вы считаете "стандартным" деревом, которое подойдёт для большинства случаев (как std::vector для contiguous контейнера).


How can I use a std::map with std::weak_ptr as key?

А с item.Lock()/Unlock() меньше возни и никогда ничего не застрянет . И item.data() в Release сборке никогда не вылетит. Ну дело хозяйское.

То Вы чай без сахара пьёте, то Вам weak_ptr громоздкий .

C++ (Qt)
if (auto item_data = item.lock())
{
    item_data->doSomething();
    ...
}

Что тут громоздкого?

Да, с таким gsl::owner (ака T*)... как говорится: "Кому и кобыла невеста." )). Скопируется такой owner несколько раз, столько же раз память кто-то освободит. Веселье обеспечено.


observer_ptr хоть и очень похож на голый указатель, но может уберечь от подобной чуши:

C++ (Qt)
#include <experimental/memory>
 
int main()
{
    using namespace std;
    using namespace std::experimental;
 
    auto u = make_unique<int>(42);
 
    int* p = u.get();
    unique_ptr<int> a{p}; // Compiled.
    delete p;             // Compiled.
 
    observer_ptr<int> o{u.get()};
    unique_ptr<int>   b{o}; // Not compiled.
    delete o;               // Not compiled.
}

Вероятность, что в коде где-то проскочит unique_ptr<int> a{p} хоть и маленькая, но не нулевая.


Хоть умные указатели не обязаны отслеживать удаление, такая функциональность может быть полезна. Созданные связи между объектами нужно разрывать, когда один из них удаляется. Взять тот же QLabel::buddy. Когда дружбан удаляется, buddy в QLabel должен занулиться. Теоретически правильный путь - это рассылка сообщений (дружбан погиб) и реакция на них (занулить, возложить цветочки). Но не всегда есть возможность делать коннекты, рассылать сообщения и т.п. И даже когда такая возможность есть, то, если надо только занулить обозревателя и больше ничего делать не нужно, использование QPointer или другого самозануляющегося weak может быть эффективнее, чем создавать коннекты и рассылать сообщения. Так что я не стал бы так просто отмахиваться от возможности самозанулиться для weak. Особенно в многопоточности.


Не все weak должны быть trackable (самозануляться, иметь проверку на валидность). Когда есть гарантии, что владелец живёт дольше обозревателя, такая функциональность может быть избыточной, и тогда достаточно голого указателя (обёртки на ним). Потому что за функциональность "проверка на валидность" нужно платить дополнительными операциями в runtime, что не всегда оправдано.

Так что weak/observer всякие нужны, и умные и простые, чтобы можно было выбрать оптимальный вариант исходя из конкретной ситуации.


То, что реализация Qt позволяет отстрелить себе ноги - так себе аргумент. А чтобы lock() не утомлял, нужны унифицированные алгоритмы доступа. И вот такая штука была бы полезна: Initial Idea of Indirect If Statement.

Правильно. Осталось только выяснить, как будет себя чувствовать вектор с неперемещаемыми not_null<unique> .


Есть такое мнение: Abandon observer_ptr.

Что "destructive move" ещё в природе не существует, то я в курсе. Правда ещё не изучал внимательно, что там предлагают. Я всё пытаюсь расшифровать это высказывание Саттера:

С одной стороны запрещают перемещение not_null, чтобы он не оказался в невалидном состоянии, с другой он говорит, что "relocation/destructive move" чем-то поможет. Я явно что-то упускаю в логике Саттера . Возможности только "returning a local not_null<unique_ptr<T>> by value", по-моему, маловато будет для полноценного использования not_null<unique>.

Одно другому не мешает . Те же самые умные указатели std при перемещении "зануляются" в реализации, что соответствует переходу в "пустое" состояние для optional-like объекта. И выглядит это вполне логично:

C++ (Qt)
#include <memory>
#include <iostream>
 
class Label
{
public:
    using Caption = std::unique_ptr<std::string>;
 
    Label() = default;
    explicit Label(Caption caption) noexcept
        : m_caption{std::move(caption)}
    {}
 
    Caption releaseCaption() noexcept
    { return std::move(m_caption); }
 
    void print() const
    {
        std::cout << "Caption: " << (m_caption ? *m_caption : "[none]")
                  << std::endl;
    }
 
private:
    Caption m_caption;
};
 
int main()
{
    Label label{std::make_unique<std::string>("Hello!")};
    label.print();
    label.releaseCaption();
    label.print();
}

Как будет выглядеть Label::releaseCaption(), если придётся вручную переинициализировать m_caption?