[Development] The future of smart pointers in Qt API

[Giuseppe D'Angelo]

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?


>> * 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?
> 
> 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;


> If we can resue the STL implementation, that's a good thing, but it
> should be an implementation detail; and I don't think we should care
> about NIH, when we are talking of classes that are unlikely to pose a
> great maintenance burden.

1) It's still NIH;
2) The probability of future C++standards  adding features that won't be 
available in the Qt counterpart is 100%;
3) Explain why Qt should raise arbitrary interoperability barriers 
literally "for the sake of it";
4) Please justify the teachability efforts involved in explaining all of 
the above to Qt users.


Cheers,
-- 
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/20200201/033ebaef/attachment.bin>