D10341: Allow move semantics to be generated for KFileItem. The existing copy constructor, destructor and copy assignment operator are now also generated by the compiler.

[Mark Gaiser]

markg created this revision.
markg added reviewers: dfaure, mwolff.
Restricted Application added a project: Frameworks.
Restricted Application added a subscriber: Frameworks.
markg requested review of this revision.

REVISION SUMMARY
  This allows the compiler to generate:
  
  - Move constructor
  - Move assingment
  - Copy constructor
  - Copy assignment
  - Destructor
  
  This in turn allows further KFileItem optimization throughout KIO and Dolphin.
  Also added a quite minimal test to see if move semantics work.
  
  As implemented now it roughly follows the "rule-of-five-default": http://scottmeyers.blogspot.nl/2014/03/a-concern-about-rule-of-zero.html
  I was tempted to go for the "rule-of-zero" which means not implementing any of those functions (thus the compiler generates them), but that - in my opinion - is not really clear as it's easy to add the destructor and then be surprised by not having move 
  semantics anymore.

TEST PLAN
  New test for move semantics (it passes, would probably pass without as well but just be a copy).
  Existing relevant tests (kfileitemtest and kdirmodeltest) all pass just fine.
  Running the new "testMove" through callgrind shows that the move constructor and assignment operator are really being used by that test.

REPOSITORY
  R241 KIO

BRANCH
  kfileitem_move

REVISION DETAIL
  https://phabricator.kde.org/D10341

AFFECTED FILES
  autotests/kfileitemtest.cpp
  autotests/kfileitemtest.h
  src/core/kfileitem.cpp
  src/core/kfileitem.h

To: markg, dfaure, mwolff
Cc: #frameworks, michaelh, ngraham
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20180206/b253299b/attachment.html>