3 ms·
It should be, but it's very much not in the real world at least as far as I've seen. Using std::move for anything other than "unique ownership without pointers
by jvanderbot 2y ago
It should be, but it's very much not in the real world at least as far as I've seen.
Using std::move for anything other than "unique ownership without pointers" really messes things up. People put std::move everywhere expecting performance gains, just like we used to put "&" everywhere expecting performance gains. It's a bit of cargo cultism that can be nicely dispelled by realizing std::move is just std::copy with a compiler-defined constructor invocation potentially run to determine the old value. With that phrasing, it's hard to hallucinate performance gains that might come automatically.
- colejohnson66 2y agoIn fact, using std::move everywhere can actually make your performance worse! https://devblogs.microsoft.com/oldnewthing/20231124-00/?p=109059 https://devblogs.microsoft.com/oldnewthing/20231124-00/?p=10...
- gpderetta 2y ago> std::move is just std::copy with a compiler-defined constructor invocation potentially run to determine the old value I have no idea what that means. std::move is a cast to an rvalue reference. That can potentially trigger a specific overloaded function to be selected and possibly, ultimately, a move constructor or assignment operator to be called. For an explicit move to be profitable, an expression would have otherwise chosen a copy constructor for a type with an expensive copy constructor and a cheap move constructor. std::copy is a range algorithm, not sure what's the relevance.
- jvanderbot 2y agoYes, typed too fast. I meant the explicit copy constructor. Luckly, HN will hide my garbage text quickly enough. Thanks for the correction!