[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