On 13/06/2019 14.13, Daniel Teske wrote: > On June 12, 2019 23:13:14 Matthew Woehlke wrote:>> Generally, if you follow > three rules:>>>> - If you create an object on the stack, either don't parent it or ensure>> its parent outlives it. (Usually not hard!)>> - If you create an object with `new`, **create** it with a parent.>> - Otherwise use a smart pointer (QScopedPointer or QSharedPointer)¹.>>>> ...you just won't have problems.> > And that doesn't need to change with my design at all. To be fair, I was responding more to Giuseppe and had only briefly looked at the original mail. In particular, I was responding to the part where he quotes your example:
>>>>> QMenu menu; >>>>> auto act = std::make_unique<QAction>("Action!"); >>>>> menu.addAction(act.get()); IMHO that code should never exist, and should not be encouraged. Leaving aside that one could use QMenu::addAction(QString) here, even in other cases similar to this where that would not apply, I would encourage following one of my first two rules instead. That's one of the things I love about Qt; object hierarchies give me working dynamic memory management without needing even smart pointers. With that out of the way, and having gone back and looked more closely at your original post... > To reiterate a point that seems to be a source of misunderstanding, > in the design I proposed the vast majority of objects are never owned > by a unique_ptr. Most objects are created with a parent. > > And there are small benefits that even those that don't want to use > unique_ptr, can get with minimal effort. For example by using the new > makeChild function: > > parent->makeChild(...); ...this actually seems pretty reasonable to me, especially as it only needs to touch the API for 1-2 classes (QObject, maybe QWidget). You're just providing an alternate way of following my second rule, which is arguably better, especially by modern C++ standards, as a) it never uses a bare `new`, and b) it works with QObject subclasses that have bad ctors that don't take a parent. (I admit I've written a few, though usually that is because the particular class is not expected to be heap allocated, or is expected to be lifetime-managed in some other manner.) Mostly what I don't want to see (and I'll freely admit this is probably a result of others' fixation) is suddenly having to litter my Qt code with `std::make_unique` and `std::move` all over the place for no more lifetime safety than I've always had. > So, I think what I have actually proposed has zero costs to those that > don't want to use it, while enabling those that e.g. want to make use of > tooling around memory managment capable of doing so. My "concern", and possibly why everyone fixated on the unique_ptr stuff, is how wide-sweeping the necessary API changes will be. Modifying every method, everywhere, that reparents a QObject is a little intimidating. (Maybe you have some WIP that can put this into perspective?) Adding (templated) QObject::createChild is much more approachable (and also conveniently dodges having anything to do with STL, which can be a hot-button issue on its own). I suspect if you were to pursue that separately, it would have a good chance of being accepted, and with many fewer passions inflamed in the process. -- Matthew _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development