[Development] The future of smart pointers in Qt API

Vitaly Fanaskov vitaly.fanaskov at qt.io
Fri Jan 31 23:46:01 CET 2020


> What would you then name a Qt counterpart of std::unique_ptr, considering that
>  QScopedPointer is not such a counterpart?

I'd suggest QUniquePointer. Honestly, I don't think we have too many alternatives here. We can try Rust-like naming (something like QBox), but it just looks weird and tells nothing about ownership semantics.

After that we can write "using QScopedPointer = QUniquePointer" for people who get used to old scoped pointer and want to highlight the fact that a resource will be released at the end of the scope. But personally I think we don't need to have one more entity without a real reason to do that.

´╗┐On 31/01/2020, 21:07, "Development on behalf of Ville Voutilainen" <development-bounces at qt-project.org on behalf of ville.voutilainen at gmail.com> wrote:

    On Fri, 31 Jan 2020 at 21:23, Alberto Mardegan
    <mardy at users.sourceforge.net> wrote:
    >
    > Old man here:
    >
    > On 31/01/20 13:07, Vitaly Fanaskov wrote:
    > > But how to use them in the API and which way is preferable is still
    > > unclear. There are two main options we have:
    > >
    > > 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.
    >
    > 2.
    >
    > I still have trouble understanding why std::unique_ptr is called like
    > this, whereas I could immediately understand what QScopedPointer does
    > even before reading its documentation.
    
    What would you then name a Qt counterpart of std::unique_ptr, considering that
    QScopedPointer is not such a counterpart?
    _______________________________________________
    Development mailing list
    Development at qt-project.org
    https://lists.qt-project.org/listinfo/development
    



More information about the Development mailing list