[Development] The future of smart pointers in Qt API
Daniel Teske
qt at squorn.de
Tue Feb 4 19:54:00 CET 2020
Am 04.02.2020 um 13:22 schrieb Konstantin Shegunov:
> On Tue, Feb 4, 2020 at 12:15 PM Vitaly Fanaskov <vitaly.fanaskov at qt.io
> <mailto:vitaly.fanaskov at qt.io>> wrote:
>
> I think, if we decide to re-implement parent-child model using smart
> pointers, we would not use unique pointers at all. Even in a methods
> like QObject::makeChild (because ownership is already defined).
> Shared +
> weak pointers make perfect sense here.
>
>
> You have to be really crafty. Allocating on the stack is a thing, you
> know, even for parent-child trees, so how do you intend to handle
> that? Are we again in "forget the stack and new everything" land?
>
Same as before, in essence a stack object is equivalent to a unique_ptr
object.
Thus:
There's no problem with having a QObjects without a parent on the
stack/in a unique_ptr.
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.
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.
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.
daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20200204/3178cb9b/attachment.html>
More information about the Development
mailing list