[Development] The future of smart pointers in Qt API

[Vitaly Fanaskov]

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.

How did you come to this conclusion?
Let me elaborate a bit. My suggestion was in using smart pointers for newly added API and transfer old API when we have time for it. It makes sense if we decide using smart pointers, I think.

* There's existing tooling around unique_ptr, and there would be none for any wrappers.
Which tooling do you mean?

On 1/31/20 2:23 PM, Daniel Teske wrote:
Hi,

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.

Also I'm sad to see that instead of using public mailing lists, you seem to have discussed this extensively internally.

For sure, it should only be a choice for newly designed API.
How did you come to this conclusion?

1) Use std::*  smart pointers as-is.

2) Add Qt-style wrappers around std::* smart pointers and move old
implementations of Qt smart pointers to the Qt5Compact module.

Both options have pros and cons. It would be useful to hear your
thoughts on it. It’s worth mentioning that some other options, like
using Qt smart pointers as-is, were also discussed. They were found less
suitable, but feel free to share your opinion if you disagree.

Using a standard class as is the right answer, because:

* Qt should position itself so that it benefits from innovation happening in the standard. Greater interoperability should be a goal. (Not just for smart pointers, but in general.)
* There's existing tooling around unique_ptr, and there would be none for any wrappers.
* Mixing std code and qt code is easier when they use the same vocabulary types.
* The existing smart pointers in qt have less capable API than the std ones.
   Expecting this to be different the next time seems foolish.
* unique_ptr is 9 years old. It's behaviour is well understood in the wider C++ community.
* There's a feeling that Qt has a NIH problem in the wider C++ community

daniel



_______________________________________________
Development mailing list
Development at qt-project.org<mailto:Development at qt-project.org>
https://lists.qt-project.org/listinfo/development


--
Best Regards,

Fanaskov Vitaly
Senior Software Engineer

The Qt Company / Qt Quick and Widgets Team
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20200131/be3fc02f/attachment-0001.html>