[Development] The future of smart pointers in Qt API

Vitaly Fanaskov vitaly.fanaskov at qt.io
Sat Feb 1 22:55:28 CET 2020


>   The consensus was reached against such a decision. A scoped pointer 
>   should not be able to escape scope. Yes, in C++17 this is now not 
>   entirely true, but the name strongly implies it.

Perhaps, it's a good time to reconsider it. Scoped pointer is redundant entity in light of modern C++. It's just an unique pointer without move semantic. Please, give me at least one example when I cannot replace scoped pointer with unique pointer without losing readability and maintainability. Unique pointer could "escape a scope" only explicitly. So I'm still not convinced that we need to have one more redundant entity. We have more than enough. This is possible to introduce an alias just to keep naming convention people get used to, I guess, but I'm not sure if this is really required.

> About QUniquePointer: what's the point of reinventing std::unique_ptr 
> under a different name?

So, first of all, not reinventing. I'd say adopting. The main question I see through some your posts in this thread is "why do we need Qtish wrappers at all?". Correct me if I'm mistaken, please. Until that I'll answer this question __
There are a few pros of having Qt wrappers around std smart pointers. To make it clear, saying "Qt wrapper" I mean a class that contains std smart pointer as a field and has more Qtish interface. Not inherits a std smart pointer.

Pros I can see:
1) Qt style
STL has different naming convention that looks alien to Qt API. It leads to inconsistency. STL is not a part of C++ language itself and cannot be considered as a default standard.
The fact that some people might get used to some names doesn't mean that these names are good in terms of self-explanatory. For example, how do I understand without documentation what does "weak_ptr::lock" do? Something like "asStrongRef" is easily understandable just by reading code.
I'm not 100% sure who is responsible for naming STL classes and methods, but this person(s) did really good job in terms of reducing symbols count. I'm just wondering why not "w_p::l" instead of "weak_ptr::lock", it looks much shorter!  In my opinion, we shouldn't sacrifice readability to reduce symbols count.
After all, many Qt users get used to Qt naming convention and style.

2) Flexibility
It will be much easier to extend or reduce interface if we need it. Changing implementation is also will be easier if someone needs to have a different smart pointers under the hood on some platforms.

3) Low maintenance costs
We just need to replicate an API at first implementation. After that, introducing new methods that might occur in an upcoming standards should be easy enough.

4) Easy to integrate with std smart pointers
A few constructors/operators/methods could solve this problem. It means that it should be possible to integrate with a code written with using std pointers.

Finishing this, I'd like to say that having consistent APIs that don't violate principle of less astonishment is important thing. That's the main reason why personally I vote for the option with Qt wrappers.

On 01/02/2020, 00:48, "Giuseppe D'Angelo via Development" <development at qt-project.org> wrote:

    On 31/01/2020 23:46, Vitaly Fanaskov wrote:
    > 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" 
    
    The consensus was reached against such a decision. A scoped pointer 
    should not be able to escape scope. Yes, in C++17 this is now not 
    entirely true, but the name strongly implies it.
    
    About QUniquePointer: what's the point of reinventing std::unique_ptr 
    under a different name?
    
    * Is it just going to be an alias, to be more Qtish? Then why 
    QSharedPointer is NOT going to be an alias?
    
    * Is it not going to be an alias? NIH all over again?
    
    My 2 c,
    -- 
    Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer
    KDAB (France) S.A.S., a KDAB Group company
    Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
    KDAB - The Qt, C++ and OpenGL Experts
    
    



More information about the Development mailing list