I like the use of explicit std::move to specify intent at the callsite. I'd love the same for std::copy, as in: a = std::copy(b). Right now my containers/etc have a copy_from method with implicit copies disabled, but I'm sure I could engineer something trivial for this.
-
-
Vastauksena käyttäjälle @Donzanoid
I disagree, but not because you're not right with the intent, but because that's not what std::move() is for. std::move() is an artifact of the language semantics (rvalues vs rvalue references). Move semantics are non obvious and implicit in most cases
1 vastaus 0 uudelleentwiittausta 2 tykkäystä -
Vastauksena käyttäjille @Manu343726 ja @Donzanoid
You are not specifying the intent at the call site because in most cases explicitly moving an lvalue is a bug or a potential bug. For example: return std::move(foo); // RVO broken, you just converted a noop into a move Foo foo; f(std::move(foo)); // foo still alive, but broken
4 vastausta 0 uudelleentwiittausta 1 tykkäys -
Vastauksena käyttäjille @Manu343726 ja @Donzanoid
This is a bit of an aside, but while your first case is certainly better just as RVO, the second case is perfectly fine and encouraged in certain cases. Example: Functions that intend to “clone and own” arguments should take by value and let the caller decide move or copy.
1 vastaus 0 uudelleentwiittausta 0 tykkäystä -
Vastauksena käyttäjille @tloch14 ja @Donzanoid
Only if the function doing that acts like a "sink": f(A a) if condition return g(move(a)) else mutateA(a) ... saveA(move(a)) No dangling moved object used in any branch
1 vastaus 0 uudelleentwiittausta 0 tykkäystä
Yes. Definitely what I meant by clone and own.
Lataaminen näyttää kestävän hetken.
Twitter saattaa olla ruuhkautunut tai ongelma on muuten hetkellinen. Yritä uudelleen tai käy Twitterin tilasivulla saadaksesi lisätietoja.