[Development] The future of smart pointers in Qt API

[Vitaly Fanaskov]

> An alias from what to what? I'm a bit lost now.
Something like: "using QScopedPointer = const std::unique_ptr". If we 
want an exact match. I think that this is also possible to omit "const" 
(yes, I know that some people would disagree).

> But the premise of the of the argument was: "give me at least one 
> example when I cannot replace scoped pointer with unique pointer 
> without losing readability and maintainability". If we accept that 
> fallacy, I can also replace any unique pointer usage with a shared 
> pointer one.
Which was not a fallacy, for the reasons I explained earlier. Comparing 
two fundamentally different items is not the same as comparing two 
fundamentally the same items. I'm assuming the situation we have now, 
not an imagine or an ideal situation.


As I said, I don't want to continue the topic about C++ standard here.


Regarding other questions about maintainability of wrappers and so on. 
I've read them, and I tend to agree that it would not be easy to 
maintain all of this thing under the circumstances we have. 
Unfortunately, this is the most significant point in this discussion.

On 2/3/20 3:37 PM, Giuseppe D'Angelo wrote:
> Il 03/02/20 14:59, Vitaly Fanaskov ha scritto:
>>> 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? 
>> Well, I hope it was rhetorical question, please, let me know if not.
>
> Yes, it was.
>
>> The difference between shared pointer and unique pointer is 
>> fundamental. But there is no fundamental difference between unique 
>> pointer and scoped pointer. The both uniquely own a resources and 
>> resource lifetime is equal to smart pointer lifetime unless it 
>> explicitly prolonged. The only difference is a way how you can do 
>> that. In case of scoped pointer you can invoke method "take", in case 
>> of unique pointer you can also use move semantic. Looks like that 
>> scoped pointer is just yet another redundant entity.
>
> A scoped pointer shouldn't have a take() function (or anything 
> similar). That's an API mistake: it enables the pointer to escape the 
> smart pointer, which is exactly what the name says it can't happen.
>
> Let's see a bit further over there:
>
> * boost::scoped_ptr: no release() (*)
> * std::unique_ptr: release()
> * std::lock_guard / scoped_lock: no release()
> * std::unique_lock: release()
>
> (*) Argument by Authority:
>> https://www.boost.org/doc/libs/1_72_0/libs/smart_ptr/doc/html/smart_ptr.html#scoped_ptr_frequently_asked_questions 
>>
>
> I do agree that the type is "redundant" because it's equivalent as a 
> const unique_ptr (as said in the other email).
>
> But the premise of the of the argument was: "give me at least one 
> example when I cannot replace scoped pointer with unique pointer 
> without losing readability and maintainability". If we accept that 
> fallacy, I can also replace any unique pointer usage with a shared 
> pointer one.
>
>
>> Introducing an alias should satisfy some people who used to use 
>> scoped pointer.
>
> An alias from what to what? I'm a bit lost now.
>
>
>>>> std::unique_ptr<Foo> ptr = ~~~;
>>>> return ptr; 
>> For example. With a scoped pointer it's a bit harder to do that, but 
>> also possible, I think, for example:
>>
>> QScopedPointer<Foo> ptr = ~~~;
>> return QScopedPointer<Foo>(ptr.take());
>
> This, unfortunately, shouldn't be possible; it's an API mistake. I 
> believe it was raised during the same discussion of making 
> QScopedPointer movable, but we never actually fixed it.
>
>
>>> What? This is absurdly false -- the Standard Library is part of the 
>>> C++ standard itself. 
>> Which doesn't mean that this is a part of the *programming language*. 
>> If you read carefully some parts of the standard, you can notice 
>> that, for example smart pointers or containers are not mandatory. For 
>> example:
>>
>> "This Clause describes components that C ++ programs may use to 
>> organize collections of information."
>
> The claim was: "STL is not a part of C++ language itself and cannot be 
> considered as a default standard."
>
> The claim was false. It is a part of the programming language, and it 
> it standardized, and any conforming implementation must ship it. The 
> specification is called "International Standard ISO/IEC 14882:2017(E) 
> – *Programming Language* C++" (emph mine) and it includes the standard 
> library.
>
> Now parts of the standard library are optional in freestanding 
> implementations. Which we don't care about anyhow.
>
> Qt since 5.0 requires the presence of a Standard Library. We worked 
> around missing bits by not making them hard requirements, but the more 
> we move forward in Qt 6, the more aggressive we'll be with these 
> requirements on compiler vendors.
>
>
>>> 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. 
>> It's not a big issue if we have Qt wrappers around std smart 
>> pointers. A standard smart pointer that is under the hood should be 
>> easily accessible.
>
> And I keep asking the details: what is not good enough in the standard 
> smart pointers to justify a reimplementation in Qt? How does this 
> trade off with the other points I've made? (Interoperability, 
> maintenance, teachability, etc.)
>
>
>>> How do you integrate QSharedPointer with std::shared_ptr exactly? 
>> If QSharedPointer is just a wrapper around std::shared_pointer it 
>> should be easy. Adding one more constructor and an operator to the 
>> wrapper.
>
> Same set of questions here.
>
> My 2 c,

-- 
Best Regards,

Fanaskov Vitaly
Senior Software Engineer

The Qt Company / Qt Quick and Widgets Team