[Development] The future of smart pointers in Qt API
andre at familiesomers.nl
Fri Jan 31 17:41:09 CET 2020
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
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
More information about the Development