[Development] [API] homogenising pimpled value class copying and moving
thiago.macieira at intel.com
Tue May 8 19:01:41 CEST 2012
On terça-feira, 8 de maio de 2012 16.57.47, Marc Mutz wrote:
> > Between a move constructor and QSharedDataPointer, I'd rather stay with
> > the
> > latter. It avoids the manual reference counting, which may include subtle
> > errors.
> The manual reference counting reduces to calling ref() in the copy ctor and
> deref() || delete in the dtor, thanks to the copy-swap idiom.
Don't forget the detaches in all the non-const functions.
> > An alternative is to use C++11 extern template declarations alongside an
> > export macro. It's a solution I had tried and worked in
> > QDBusUnixFileDescriptor, using GCC's equivalent C++98 extension.
> This doesn't sound like the code ends up inline, though. Do you have a
> change set so I can look at it?
Look at the history of src/dbus/qdbusunixfiledescriptor.h.
The move constructor remains inline.
The destructor doesn't end up inline because the
QSharedData<QDBusUnixFileDescriptorPrivate> class is extern template. The
interesting thing is that dead-code removal removes the call to the destructor
of the private type because it can't happen.
> BC is only one reason to have the move ctor inline. The other is speed.
> Moving should be blazingly fast, and jumping into a so/dll to perform it
> sounds like premature pessimisation :)
The regular copy constructor is fast enough. There's no need to make the code
worse to read for minimal gain.
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Intel Sweden AB - Registration Number: 556189-6027
Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 190 bytes
Desc: This is a digitally signed message part.
Url : http://lists.qt-project.org/pipermail/development/attachments/20120508/84679b6d/attachment.bin
More information about the Development