[Development] [API] homogenising pimpled value class copying and moving

Thiago Macieira 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: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120508/84679b6d/attachment.sig>


More information about the Development mailing list