[Development] The future of smart pointers in Qt API

[Giuseppe D'Angelo]

Hi,

Il 01/02/20 22:55, Vitaly Fanaskov ha scritto:
>>    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.

If we're going for this logical fallacy, then let's up the ante: a 
unique pointer is just a shared pointer without copy semantics. Why not 
using shared pointers everywhere?


> Please, give me at least one example when I cannot replace scoped pointer with unique pointer without losing readability and maintainability. 

And an example where I cannot replace a unique pointer with a shared 
pointer without losing readability and maintainability?


> Unique pointer could "escape a scope" only explicitly. 

Like this?

> std::unique_ptr<Foo> ptr = ~~~;
> return ptr;



> So I'm still not convinced that we need to have one more redundant entity. 

Which one would be the redundant one?


> 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. 

That's the question indeed. What's the tangible net benefit of having a 
Qt wrapper?


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.

And I've asked: how this Qtish interface for std::unique_ptr be 
different exactly?


> 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.

What? This is absurdly false -- the Standard Library is part of the C++ 
standard itself.


> 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.

With this I can totally agree. As I said countless times, the only way 
to influence such naming decisions is working _with_ upstream (by the 
way, the meetings are pretty much public) and bringing your arguments on 
naming there. After, it's too late, and as an overall minority in C++ 
we'll get those decisions made by someone else and we'll just have to 
live with them. It's not a good position to be in.

Between C++11, 14, 17 and 20, by heart I can only name _one_ thing that 
has been introduced in the Standard Library which has had an inspiration 
coming from Qt (C++20's std::map::contains()).


Please also see this from the eyes of someone else who comes from a 
general purpose C++ background, where usage lock() is established (for 
how much absurd that naming choice is); then gets the Qt equivalent, and 
wonders why it _hasn't_ got lock(), despite Qt having 0.something% of 
the C++ market share.

(I know QWeakPointer has got lock() now.)


> 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.

The "who" is a lot of people.

> https://isocpp.org/std/the-committee



> After all, many Qt users get used to Qt naming convention and style.

And again see this the other around too: many C++ users get used to the 
C++/Boost/Abseil/... naming convention and may find Qt ones "unusual".



> 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.

Changing the interface in any way which are incompatible with the 
Standard counterparts is a _terrible_ idea. It kills the principle of 
least surprise; it makes such facilities incompatible with the STL 
counterparts, preventing interexchange of data and code; and come Qt 
(N+1), it will prevent a clean pass of s/QtFoo/std::foo/g over the codebase.



> 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.

This is wishful thinking, or, famous last words.

First: it costs in terms of development bandwidth that is NOT being used 
to improve the areas where Qt should shine; it's instead used for 
reinventing wheels.

Second: history proves this false. See for instance the story with Qt 
containers, which are *still* missing range insertion (C++98) (and some 
range construction), emplacement (C++11), support for move-only types 
(C++11), and so on. On what grounds should one believe that after 9 
years suddenly Qt will catch up with the development of these building 
blocks?


> 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.

How do you integrate QSharedPointer with std::shared_ptr exactly?



> 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.

If I were a developer coming from standard C++ to Qt, the principle 
would apply in that direction too: why in the world Qt felt the need to 
reinvent all my vocabulary types?

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4329 bytes
Desc: Firma crittografica S/MIME
URL: <http://lists.qt-project.org/pipermail/development/attachments/20200202/b101c4ae/attachment.bin>