[Development] The future of smart pointers in Qt API

[Иван Комиссаров]

Do I understand correctly that proposition of usage of the shared_ptr instead of unique_ptr is to have a drop-in replacement for a QPointer (weak_ptr)?
Can we implement It somehow with the unique_ptr?

And what about the QObject::deleteLater() method? I always found it pretty ugly (what if that «later» will never happen, e.g. event loop gets interrupted?), but it has the use case - to safely delete an object after the slot was invoked. Any ideas how this should look like with smart pointers?

> 31 янв. 2020 г., в 15:14, Vitaly Fanaskov <vitaly.fanaskov at qt.io> написал(а):
> 
> 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 <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 <https://lists.qt-project.org/listinfo/development>
> -- 
> Best Regards,
> 
> Fanaskov Vitaly
> Senior Software Engineer
> 
> The Qt Company / Qt Quick and Widgets Team
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20200201/1c7eeac0/attachment-0001.html>