Современный C++ давно говорит «забудь про new». Qt говорит «подожди». Статья разбирает, почему иерархическая модель фреймворка и RAII плохо живут вместе.
•
QObject с родителем удаляется деструктором родителя. Если при этом он ещё и под unique_ptr — получишь double free: умный указатель не знает, что объект уже мёртв.•
QWeakPointer как аналог слабой ссылки здесь не поможет — он работает только с QSharedPointer, который в Qt-иерархии использовать нельзя. Для этого есть QPointer<T>, который подписывается на destroyed() и обнуляется сам.•
sender() возвращает QObject* — объект, которым уже кто-то владеет. Оборачивать результат в умный указатель — значит воевать с фреймворком.• В
QML ситуация хуже: JS GC может удалить переданный из C++ объект без родителя, не предупредив. Краш случится через непредсказуемое время. Спасает только QQmlEngine::CppOwnership или явный родитель.•
QScopedPointer имеет смысл перед std::unique_ptr в одном конкретном случае — QScopedPointerDeleteLater для объектов вроде QNetworkReply, которые нельзя удалять немедленно. В остальном std-аналоги легче и лучше интегрируются с внешними библиотеками.💡 Решение предлагается в статье в виде правила:
• есть родитель -> сырой указатель,
• нет родителя ->
QScopedPointer или std::unique_ptr • нужно следить за чужим объектом -> только
QPointer• бизнес-логика без
QObject -> чистый STL.✏️ Статья
📍Навигация: Вакансии • Задачи • Собесы
Библиотека C/C++ разработчика
#линкер_рекомендует