[Development] The future of smart pointers in Qt API

[Giuseppe D'Angelo]

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,
-- 
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/20200203/ee900ecf/attachment.bin>