[Development] The future of smart pointers in Qt API

[Giuseppe D'Angelo]

On 02/02/2020 17:38, Alberto Mardegan wrote:
> On 01/02/20 15:32, Giuseppe D'Angelo via Development wrote:
>> Il 01/02/20 12:37, Alberto Mardegan ha scritto:
>>> Do we need to have such a counterpart? In my work experience, when I'm
>>> not allowed to use Qt and am restricted to the STL, all the times I had
>>> to use std::unique_ptr was to get the same behaviour as a QScopedPointer.
>>
>> So you never had to pass one to a function, return one from a function,
>> create a vector of them? Color me *very* suspicious.
> 
> Believe it or not :-) I find std::shared_ptr easier to use when passing
> pointers to and from functions. And I never needed to put them into an
> array.

This is a logical fallacy; "I don't need it, noone else does".


>>> So, I don't really care about std::unique_ptr, but I like Vitaly's
>>> suggestion of having a QUniquePointer with a nice data() method.
>>
>> How about working with upstream and convincing them that having data()
>> (in addition to get()) on smart pointers is a good idea? Is having
>> data() the _only_ argument here?
> 
> The STL could still add a method made up of two words in the future, and
> it's unlikely that they'll use camelCase (or that they'd accept a
> camelCase variant).

And I still see no problem in that? What is the problem at looking a bit 
outside one's comfort zone (or one's bubble) and realizing that simply 
because the Standard Library uses snake_case, we can live with it just 
fine?

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/65989235/attachment.bin>