Hi Daniel, Thanks for the nice work of looking to use unique_ptr, I like it, I think it makes ownership clearer. About having wrappers or not I am still on the fence, I think using stl when possible is a good idea, but I see the advantage of having consistent naming, so I am not sure about the best option. Still I find the idea of using unique_ptr in the API as you proposed a good thing. -- Fawzi Mohamed Senior Software Developer
The Qt Company Address Erich-Thilo-Str.10D-12489, Berlin, Germany fawzi.moha...@qt.io +49 30 63 92 3255 http://qt.io The Future is Written with Qt -- > On 2. Feb 2020, at 23:30, Daniel Teske <q...@squorn.de> wrote: > > > Am 02.02.2020 um 18:17 schrieb Иван Комиссаров: >> Can we please return to the discussion about QObject parent/child with smart >> pointers rather than discussing Qt/stl naming? >> >> No one answered my question about QObject::deleteLater: >> >>> And what about the QObject::deleteLater() method? Any ideas how this should >>> look like with smart pointers? > > So obviously this: > > std::unique_ptr<> ptr; > ptr->deleteLater(); > > should show a warning. Thus, the first step is to annotate deleteLater with a > optional deprecation. > > Then two new functions need to be added: > > static QObject::deleteLater(QObject *ptr) > > which does not violate that invariant. (Unless you take a pointer out of a > unique_ptr and pass it in.) > > And a second variant: > static QObject::deleteLater(std::unique_ptr<QObject> ptr) > > which quite obviously also keeps the invariant. > > I think I missed the function in my patch, but that's how you could easily do > it. > > daniel > > _______________________________________________ > 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
