> Hi Marc and others > Just never create a child QObject w/o the final parent, and everything will be peachy.
This is one of the drivers for initiative we can enforce with “makeChildObject()” and no longer encouraged “new Object(this)”. > Every function that transfers ownership as a raw pointer is worth being replaced by one taking/returning by unique_ptr. Let the API enforce ownership transfer instead of letting the reader of the code guess. I agree. So we should encourage to use pParent->addChild(std::move(pChild)) instead of pChild->setParent(pParent) > I wouldn't even assert in the destructor. That will fire already when these things are held as member functions in the "wrong" order. I am as well against an ASSERT that may crashes the productive build for a semantical reason. What is the best pattern for Qt? How about issue a qWarning during the QParentedPointer *constructor* like we have in QObject::~QObject()? I have good experience with this. So, let me summarize the latest discussion, to verify if I got it right: We will introduce: 1: Child* QObject::makeChildObject() with some template magic to automatically set the parent pointer and a static_assert for pParent == this otherwise 2: QParentedPointer<Child> with a non-fatal warning or similar if the parent is null. Disallow copy and move, because for the borrowing case we want to use raw pointer or QPointer in line with the C++ core guideline. 3: QObject::addChild(std::unique_ptr<QObject *> child) Will this have a chance to being merged upstream? Best regards, Daniel
-- Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
