[Development] The future of smart pointers in Qt API

[André Somers]

On 31-01-20 15:14, Vitaly Fanaskov wrote:
>
> Hi Daniel,
>
>> I'm confused that there's zero discussion of the work I have done in 
>> showing how adding unique_ptr apis would look like. Surely, you have 
>> internally discussed that approach. 
> Yes, I saw this patch 
> (https://codereview.qt-project.org/c/qt/qtbase/+/260618). It looks 
> good as an example of using unique pointers.
>
> My personal opinion that we have another fundamental problem in the 
> implementation of parent-child relationship in Qt. Ditto for the 
> related interfaces. The problem is that everything is implemented with 
> using raw pointers and some implicit contracts (like, "a parent 
> removes its children").  The proper solution is re-implement it using 
> smart pointers. For example, each QObject stores a vector of shared 
> pointers to children and a weak pointer to its parent. With this 
> "simple" approach we can implement proper API and get rid of entities 
> we don't really need, like QPointer for example.
>
> I don't think that adding another level of abstraction and introducing 
> new entities is such a good solution here. Better to solve a cause 
> rather than fight consequences.
>
>
I agree that Qt suffers from a problem there, but I disagree on what the 
problem is.

I think it is quite strange that in 2020 we are still using an intrinsic 
data structure to structure our object trees. We stopped doing that for 
lists a long time ago. Instead of items in the list _being_ a node that 
can be in a list, we now have all kind of data structures at allow to 
manipulate our data in whatever data structure suits us for the task at 
hand. That may be node-based list structure, or whatever else. Yet, for 
our parent-child trees, we insist that this data needs to be represented 
as a pointers between QObject instances themselves.

In my opinion, Qt should have gotten rid of these instrinsic data 
structures a long time ago. If our object hierarchy is an n-ary tree, we 
should be using a type for the data structure that represents exactly 
that. We should not let the structure of our data be an incidental 
result of objects pointing to each other.

And yes, that is such a fundamental shift, there is no way it can be 
done (any time soon) I think. Still, I hope that for new API, it may be 
a consideration.

André