On Tue, Feb 4, 2020 at 8:55 PM Daniel Teske <q...@squorn.de> wrote: > A QObject with a parent on the stack/unique_ptr is double owned and thus a > problem. The severity of that problem is arguably worse with a unique_ptr. > Which is rather typical in well structured and valid threaded code, where the children are stack allocated and are moved to the correct thread whenever the parent is moved. There's more to memory management than half-blindly throwing smart pointers at it, is my point. Say you substitute all the private objects' allocations with std::unique_ptr, the question would be what do you gain by that?
> Where my patch improves this situation is that the object ctors taking a > parent ptr are all marked with a optional deprecation, thus if you opt into > that, you'll get a warning for the second case even for the stack > allocation. > I've looked at your patch the first time you posted it on the dev list, it looked (and still does) fine to me. > And yes this contrary to very crafty code that allocates objects in the > right order on the stack, but that has never been the recommend way to use > Qt. > The right order in the stack is given if the parent already contains the children. And C++ is stack-based to begin with, otherwise people wouldn't have invented stack objects managing heap-allocated data blocks (a.k.a "smart pointers"). Even the idea of having free floating shared pointers gives me shivers. I've run on more than one occasion into easy to miss ownership pitfalls where I have had a slot executed on a QObject where the object had already been deleted by a shared pointer. My current stance is (in regards to the current state of affairs, that is) - don't use QObject with shared pointers unless you like pain often and in copious amounts. (nested event loops and/or queued events are what usually does it)
_______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
