Making modern (RAII) C++-code with Qt5
When in Qt, act like Qt.

Qt already has an ownership model, and it works by passing the parent object (as a raw pointer) in the constructor (so there's no window of exception-triggered leakage).  And Qt has its own weak pointers (including QObjectPointer).

I wouldn't try to outsmart Qt on pointer lifetime and ownership - but keep watching development, and if a future version of the library starts accepting smart pointers to transfer ownership, then reach out and grab it at that time!

In my personal opinion, the code you show is less clear than the Qt-native equivalent:

#include &lt;QWidget&gt;
#include &lt;QVBoxLayout&gt;
#include &lt;QPushButton&gt;
#include &lt;QLabel&gt;
#include &lt;QObject&gt;

class MyWindow : public QWidget {
    Q_OBJECT
public:
    MyWindow(QWidget* parent = nullptr);
private:
    QLabel *const label;
    QPushButton *const button0;
    QPushButton *const button1;
    QVBoxLayout *const layout;
    int count = 0;
private slots:
    void setText();
};

#include &lt;QApplication&gt;
MyWindow::MyWindow(QWidget *parent)
    : QWidget{parent},
      label{new QLabel{"old text", this}},
      button0{new QPushButton{"Increment", this}},
      button1{new QPushButton{"Quit", this}},
      layout{new QVBoxLayout{this}}
{
    layout-&gt;addWidget(button0);
    layout-&gt;addWidget(button1);
    layout-&gt;addWidget(label);
    setLayout(layout);
    connect(button0, &amp;QPushButton::clicked, this, &amp;MyWindow::setText);
    connect(button1, &amp;QPushButton::clicked, qApp, &amp;QCoreApplication::quit);
}
void MyWindow::setText() {
    label-&gt;setText(QString{"Label updated %0 times"}.arg(++count));
}


Here, I've made the widget pointers const for safety, so we know that they will be valid for the lifetime of the MyWindow object.

I've also used the method-pointer version of connect() - I recommend this where practicable, to get more checking at compile time.  Connect by name only when you really have to, such as when you can't know the complete types of the objects you're connecting.  See also Connecting overloaded signals and slots in Qt 5 if you have trouble with overloads.



Your code and comments suggest that you're concerned about leaking memory if an exception is thrown in an initializer.  For example, consider a failure to allocate/construct button0 after label was successfully created; will label then be left in limbo?  Although our ~MyWindow() destructor is not called (and we don't even need a non-default one), its superclass destructors will be.  And that includes the ~QObject destructor, which deletes its children.  We know that label will be deleted, because its constructor returned (and adding itself as a child is among the first things it does).

None of this would be true (and we would not be exception-safe) if we forgot to include the optional parent parameter (this) when constructing label; if we were to initialize it without a parent and then its setParent() method in the body of the constructor, we would have a gap where Qt wouldn't own it properly.

We can demonstrate this by wrapping one or more of the allocations in a function.  The following code allows you to experiment with throwing exceptions for the different child objects:

int alloc_succeeds = 3;
#include &lt;stdexcept&gt;
template&lt;typename T, typename... Args&gt;
T *createWidget(Args... args)
{
    if (--alloc_succeeds &lt; 0)
        throw std::bad_alloc();
    return new T{args...};
}

#define PARENT this
//#define PARENT nullptr

#include &lt;QApplication&gt;
MyWindow::MyWindow(QWidget *parent)
    : QWidget{parent},
      label{createWidget&lt;QLabel&gt;("old text", PARENT)},
      button0{createWidget&lt;QPushButton&gt;("Increment", PARENT)},
      button1{createWidget&lt;QPushButton&gt;("Quit", PARENT)},
      layout{createWidget&lt;QVBoxLayout&gt;(PARENT)}
{


Change the value of alloc_succeeds to determine how many constructors are successful.  If we run the code under Valgrind, we see that by changing PARENT to nullptr, we can get our objects to leak (we also see some of the leaks of Qt itself, so it's helpful to run both to eliminate false positives).