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.fanas...@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@qt-project.org <mailto:Development@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@qt-project.org > https://lists.qt-project.org/listinfo/development
_______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
