[Development] The future of smart pointers in Qt API

Giuseppe D'Angelo giuseppe.dangelo at kdab.com
Sun Feb 2 20:00:56 CET 2020


On 02/02/2020 17:34, Alberto Mardegan wrote:
> On 01/02/20 15:02, Giuseppe D'Angelo via Development wrote:
>> Il 01/02/20 12:44, Alberto Mardegan ha scritto:
>>> On 01/02/20 02:46, Giuseppe D'Angelo via Development wrote:
>>>> About QUniquePointer: what's the point of reinventing std::unique_ptr
>>>> under a different name?
>>>
>>> A Qt-ish API!
>>
>> Example?
> 
> A data() method :-)

Upstream is settling on the convention of having data() on things that 
also have size(). Smart pointers lack the latter so they don't have the 
former.

Is it questionable? Sure. In principle, data() on smart pointers may 
actually be added (in the sense that it would be 100% backwards 
compatible). Do you happen to have a proposal for it?

Is this a difference so big and important to justify diverging from it? 
I am very unconvinced.


>>> It's not clear to me what you mean by "alias"; if you mean a subclass,
>>> then I'd be against it, because there's a (very small indeed) risk that
>>> in the future the STL adds some methods that might conflict with ours,
>>> or would not be Qtish enough.
>>
>> I mean a type alias: using QUniquePointer = std::unique_ptr;
> 
> It still bring the risk of the STL adding some weirdly named methods
> (such as empty()) which we don't want to have in a Qt class.

And in fact I am NOT proposing to add such an alias at all, but to use 
std::unique_ptr as-is.


>> 1) It's still NIH;
> 
> Which is not bad per se, in absolute terms.

* If it's worth economically is a question for who pays the bills.

* If it's worth technologically: I still don't see a use case that

* I can tell you for sure it's not worth from a learning (and teaching) 
point of view.


>> 2) The probability of future C++standards  adding features that won't be
>> available in the Qt counterpart is 100%;
> 
> They could be added, and the effort should be minimal (copy the code
> from STL).

There's no "code from STL". The Standard is a specification, not code. 
If you meant to copy from an _implementation_: it has not happened in 
the last 9 years (see the examples I brought in the other email), what 
grounds do you believe it will start now? (Not to mention the legal 
problems associated with this.)


>> 3) Explain why Qt should raise arbitrary interoperability barriers
>> literally "for the sake of it";
> 
> We can easily provide static fromStdUniquePtr and toStdUniquePtr
> methods, and there wouldn't be a barrier.

We could also use std::unique_ptr directly and there would be even less 
of a barrier. I asked why put this barrier in the first place, not how 
to reduce this barrier. (And I also asked about shared_ptr)


>> 4) Please justify the teachability efforts involved in explaining all of
>> the above to Qt users.
> 
> You can explain it to our users by saying that we want a consistent API,
> and that while Qt is interoperable with the STL, it can be used without
> it (and as an alternative to it).

Qt cannot be used without a Standard Library. The question for the 
future is how do we make the maximum out of it.

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: S/MIME Cryptographic Signature
URL: <http://lists.qt-project.org/pipermail/development/attachments/20200202/5d190bed/attachment-0001.bin>


More information about the Development mailing list