On 06/08/2016 21:58, Guillaume Munch wrote:
But I agree that new move functionality in C++11 is really nice and I
know that I have to unlearn the good practice I learned so many years
ago in order to use them efficiently.
The issue with c++11 move semantics is that it is an addition of a big
layer of complexity on top of the rest for backward-compatibility
reasons and that makes everything very complicated. We want to avoid
needlessly writing complicated code that few people understand.
Agreed. Indeed I've seen code with lots of lambda that is very hard to read.
I think one should think about c++11 as a new language if you really
want to take advantage of it. auto, range loop, new algorithm, etc are
very nice but mixing old style c++ and c++11 leads to confusing source code.
The most important thing to remember is the conclusion in part 3: pass
by const reference, unless the function needs a copy "conceptually". In
this case, you should pass by value. Pros:
* Simple and generic rule.
* Not a big change compared to what developers are used to.
* Exposes in the interface the knowledge of when passing an argument is
going to be expensive.
* In the latter case, offers to the caller the opportunity to move the
argument instead of copying it.
Sounds good.
***
In addition, now, what if we want to design a bulky class that relies on
being moved more often than being copied? It is possible to simply make
the copy explicit in the class declaration (say TexRow), as follows:
explicit TexRow(TexRow const & other) = default;
TexRow(TexRow && other) = default;
TexRow & operator=(TexRow const & other) = default;
TexRow & operator=(TexRow && other) = default;
(this defines respectively the copy and move constructors, and the
copy and move operators, as default.)
Making the copy constructor explicit prevents implicit copies when
passing an argument. One has to explicitly move or copy. Pros:
* It forces to think about it.
* It also prevents every cases of move(obj) unexpectedly performing a
copy instead of a move.
I still have to see whether this particular use case is not redundant
with encapsulating in a unique_ptr. But I would like to suggest that
copy constructors should be made explicit when a class is designed to be
moved, if only to avoid reading code containing move(obj) and not
knowing whether it's really a move.
Sounds good as well :-)
Abdel.
