Адаптация кода для smart pointers

А о каком конкретно указателе речь ? А то тот-же шаред поинтер имеет все необходимые перегрузки для нормальной работы.

Ну вот смотри, метод connect ждёт аргумент QObject*, я могу передать ему объект типа shared_ptr<QObject> без риска утечки памяти?

Я могу ошибаться, но в Qt как будто бы для наследников QObject принято использовать немного другую модель управления памятью, а именно - модель владения. Т.е. ты руками удаляешь только корневой объект, а остальным - должен назначить родителя.

Вроде можно и руками дочерние об’екты удалить. Главное, что у каждого есть родительский об’ект, и при его удалении, рекурсивно удаляются все дочерние об’екты. А при ручном удалении дочернего он просто выписывается из списка дочерних в своем родителе при деструкции:

https://riptutorial.com/qt/example/22800/qobject-lifetime-and-ownership

Кстати, есть ещё вот такой товарищ в этой куче API.

Нет, так, конечно, не получится. Можно передать ему указатель который ссылается на ресурс управляемый смарт поинтером (там должно быть неявное преобразование в указатель о чем я писал ранее). И все будет работать пока вы можете гарантировать что ваш смарт поинтер переживёт обьект с методом connect которому вы передаете указатель. Но смысл в использовании умных указателей в таком случае теряется.

Лень вызвать get(), в этом дело? Ну можно обёртку закостылить:

#include <memory>

template <typename T>
class My_ptr : public std::unique_ptr<T>
{
public:
	using std::unique_ptr<T>::unique_ptr; 
	operator T*() {return this->get();}
};

int main()
{
	My_ptr<int> p(new int);
	int *i = p;
}

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

Во-первых, у Qt уже есть свои smart pointers – QSharedPointer и компания. Где они нужны в API — Qt уже их принимает.

Во-вторых, shared pointers моделируют совместное владение объектом. У Qt уже модель владения QObjects типа виджетов, и она не совместная — и не совместимая с shared pointers.

В общем, нужно думать, когда какие указатели нужны и полезны.

У QObject’ов это все не нужно, им нужно родителя указать - и все.

Берите std::unique_ptr, можно вызвать метод release чтобы передать владение в обычный raw-указатель. Наоборот тоже легко делается.

Это не Qt-путь )))

Просто я прогнал код через clang-tidy, ну, тут оно и повылезало.

Хотя да, Qt слишком самобытная штука.

Где они нужны в API — Qt уже их принимает

Нихрена. Даже connect принимает сырые, и примерно всё остальное.

У Qt уже модель владения QObjects типа виджетов, и она

… не нужна в 21-м веке. Всё отлично делается на смартпойнтерах, хоть Qt-шных, хоть стандартных.

что как я читал - плохо

Либо ты не понял, либо автор. В данном случае get - то что нужно.

Конечно, каждый раз надо задуматься про время жизни объекта.

Но смысл в использовании умных указателей в таком случае теряется

Не теряется. При удалении объекта, connect’ы на него, будь то сигналом или слотом, удаляются автоматически.

Я не в курсе что там у QT в кишках, очень давно уже в нём не работал.

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

В нормальном случае, мы должны проследить что-бы наш умный указатель не самоуничтожился пока внешний код не перестанет использовать переданный в него обычный указатель. Полагаться на какую-то умную логику внутри внешнего кода - в общем случае, это bad practice, потенциальный баг и UB. Не надо так делать.

Может QT со своим постпроцессором MOC что-то с этим делает, может особым образом объявленные умные указатели или другие объекты в каких-то местах в классах QT как-то особым образом обрабатываюся, я хз. Я говорил про общий случай, я не в курсе даже что там делает connect у QT. Но полагаться на внешнюю логику в таких случаях не рекомендуется обычно.

Конкретно с коннектами - это документированное поведение, и лучше не сделаешь, и нормально работает. Опыта много.

Альтернатива - отказываться от смартпойнтеров и лепить deleteLater в событиях. Вряд ли проще.

А в общем случае всё так, да.

Всё просто: сырой указатель рассматривай как невладеющий. Qt не принимает на себя управление временем жизни объектов по указателям в подавляющем числе случаев, единственное исключение, которое приходит на ум - когда указывается парент у QObject, но это элементарно: просто никогда его не указывай.

Метод connect, естественно, удалять или перемещать объект по ссылке не будет, его же можно вызывать и для объектов на стеке.

И это общая практика в современном С++ - избегать сырых указателей любой ценой не нужно, но они всегда не владеющие.

можно нуллптр указать, кувиджеты вообще окном становятся в таком раскладе.

просто никогда его не указывай.

прощай мув-то-тред ))

Это который The object cannot be moved if it has a parent?

аха

Я могу ошибаться, но в Qt как будто бы для наследников QObject принято использовать немного другую модель управления памятью, а именно - модель владения. Т.е. ты руками удаляешь только корневой объект, а остальным - должен назначить родителя.

Этот принцип не работает, например, с QLayer и его производными? QLayer получает указатель на содержащийся в нем объект, но не становится его владельцем. Щас уже не вспомню, но и у некоторых других объектов видел такое поведение. Да, оно описано в документации, но принцип имеет для некоторых ситуаций нюансы, которые неочевидны.

Ну так QLayer не владеет виджетами, виджетами владеет виджет на котором эти виджеты расположенны, так что пример не засчитывается.

А почему бы не соблюдать иерархию, и виджету владеть QLayer, который в свою очередь владеет виджетами?

Так layer может легко заменяться в процессе работы приложения, прикажешь виджеты и их состояние пересоздавать?

Резонно, правда в моей практике такого не встречалось.