[Development] unique_ptr vs. QSharedPointer

Olivier Goffart olivier at woboq.com
Tue May 3 17:00:15 CEST 2016


Am Dienstag, 3. Mai 2016, 14:19:00 CEST schrieb Shawn Rutledge:
> > On 3 May 2016, at 13:31, Marc Mutz <marc.mutz at kdab.com> wrote:
> > 
> > On Tuesday 03 May 2016 13:14:05 Shawn Rutledge wrote:
> > 
> >> In what ways are they different?
> > 
> > 
> > One implements unique ownership, isn't copyable, only movable, has almost
> > zero overhead (with a stateless deleter), and is standardised from
> > C++11 on, the other implements shared ownership, is copyable and movable,
> > has the overhead of a separate control block, and is Qt-specific.
> 
> 
> OK.
> 
> But a function could return a unique_ptr, right? the caller of that function
> would thn be restricted from doing anything that results in a copy?

Yes, because unique_ptr is movable.


 
> >> Is it OK to use unique_ptr in public API starting in 5.7?
> > 
> > 
> > No.
> 
> 
> Because of the convention that we return only Qt data structures, never STL
> ones? or because we’re not sure if all compilers support unique_ptr?  Or
> something else?


Because of the convention that we do not want our ABI to depends on the STL's 
ABI.  So we can't use standard container in the signature of exported 
functions.


The closest we have to unique_ptr in Qt is QScopedPointer.
With the difference that QScopedPointer is not movable.
Personally, i think we should add a move constructor to QScopedPointer, but 
this has already been discussed there and the concensus was against it:
http://lists.qt-project.org/pipermail/development/2013-September/012882.html
Either we should reopen the discussion or create a QUniquePointer.
(Or we should allow std types in our ABI)

-- 
Olivier 

Woboq - Qt services and support - https://woboq.com - https://code.woboq.org






More information about the Development mailing list