[Development] The future of smart pointers in Qt API

Giuseppe D'Angelo giuseppe.dangelo at kdab.com
Sat Feb 1 13:32:05 CET 2020


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.


> It's true that QScopedPointer offers only a subset of std::unique_ptr's
> functionalities, but,*for that subset*, its name is just perfect.
> That's why I wouldn't like to see it go away, or moved to a compat library.

The same subset is available in the Standard Library. The type you're 
looking for is "const std::unique_ptr".


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

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


More information about the Development mailing list