[Development] Move assignment without move constructors

Giuseppe D'Angelo giuseppe.dangelo at kdab.com
Mon May 23 20:40:36 CEST 2016


Il 23/05/2016 19:50, Konstantin Tokarev ha scritto:
>
>
> 23.05.2016, 19:25, "Giuseppe D'Angelo" <giuseppe.dangelo at kdab.com>:
>> Il 23/05/2016 18:11, Konstantin Tokarev ha scritto:
>>>   Hello,
>>>
>>>   I've stumbled upon QPixmap having operator=(QPixmap&&) but missing QPixmap(QPixmap&&), however it seems like there are a lot of Qt classes in the same situation, for example:
>>
>> [snip]
>>
>>>   Is there any good reason for these classes to not have move constructor, or is it just an unfortunate omission?
>>
>> Because the implementation of a move constructor for those classes
>> requires the private class to be defined in the public header, but all
>> those classes are pimpl'd, so by definition you don't have that private
>> class available.
>
> Copy constructors are not defined in headers, so  don't see any reason for
> move constructors to be inline. And if those move constructors are defined in
> .cpp files, it should not be needed to include private headers into public.

Unfortunately, that was not the case before 5.7, as we
1) could not require C++11;
2) Qt claimed binary compatibility between any combination of

application compiled with/without C++11
x
Qt compiled with/without C++11.

The problem was that an application compiled with C++11 against a C++11 
Qt would use the move operations _exported_ by Qt, but then the same 
application could not run against a C++98 build of Qt (which would not 
export them). (*)

For this reason, some C++11-only bits of Qt (such the move assignment) 
was implemented as an inline function in the header, which then causes 
the problem with the private class not being defined at that point.

Since 5.7 Qt started requiring C++11, so we can implement move 
constructors too (out of line); I think we require move operations to be 
fully working, otherwise we go back to the pre-5.7 status, but I can't 
find the feature whitelist document right now.

Any takers for the task? :)



(*) I'm personally against this kind of "stretched" definitions of 
binary compatibility, but that's just my personal opinion...


-- 
Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer
KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908
KDAB - The Qt Experts

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4007 bytes
Desc: Firma crittografica S/MIME
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160523/f3b33fe4/attachment.bin>


More information about the Development mailing list