[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