4 ms·

C++ “move” semantics are simple, but they are still widely misunderstood. No, they aren't simple and the fact that are still widely misunderstood is basically

by rsp1984 7y ago

C++ “move” semantics are simple, but they are still widely misunderstood. No, they aren't simple and the fact that are still widely misunderstood is basically proof of that. Maybe, just maybe, it has something to do with stuffing rvalue references, perfect forwarding and the whole universal-references-template-clusterfuck into one and the same syntax. [1] The default compiler-generated move can leave behind a null sp member Which is precisely why std::move should be used with caution, which, in turn, is precisely why many codebases are still avoiding it. This problem in particular could have been avoided by not auto-generating move constructors. I really want to like this feature of C++, but I feel its design is just so horribly bad and confusing that I'd feel like a total d..k if I started to force it on a team of developers (of various levels of experience) if there's no crystal clear need for it (and let's be honest, C++ was already pretty successful in getting shit done before there was std::move and rvalue references). [1] http://thbecker.net/articles/rvalue_references/section_01.html http://thbecker.net/articles/rvalue_references/section_01.ht...

pingyong 7y ago
I mean requiring an explicitly defaulted move constructor or something to that effect I wouldn't mind, but personally I also think it's beyond obvious that if you move from a smart pointer that it's going to hold a nullptr after that. I wouldn't consider that hard to understand (or surprising) at all compared to something like even relatively simple thread synchronization, something that comes up for pretty much any native developer eventually these days.
DoofusOfDeath 7y ago
Let me start by saying I have tremendous respect for the people who oversee C++'s evolution. It seems like a very difficult challenge, and I believe their intentions are pure. But I agree completely with your point about "move" semantics. Some language rules that seem clear to Sutter et al are insanely complicated to normal C++ developers. Most of us could probably stay on top of C++'s rules if we spent many hours per week on that task. But few of us have the time or interest to do that.
- dragontamer 7y ago
  "Simple" is an overloaded English term. Its not that "Move is so simple that you should understand it". It seems to be "Move is so simple it doesn't actually get the job done that most people want".
hinkley 7y ago
> still widely misunderstood is basically proof of that. How much better the world would be if software developers started making judgements based on empirical evidence instead of rhetoric and navel gazing... To paraphrase the old bit: If an idiot misuses your software in the morning, you have a user who's an idiot. If idiots misuse your software all day, you're the idiot.
imron 7y ago
> No, they aren't simple and the fact that are still widely misunderstood is basically proof of that. The article disproves itself. Sure, move is simple, if you stick to that one very narrow use case (that still needs std::move() boilerplate around moves to signal intent). The problem (that the article then goes to point out) is that there are so many non-simple and buggy ways move can (and does) get used. So you don't just need to learn the simple use case (with added boilerplate), you also need to learn all the complicated buggy use cases so that you can avoid using them. For actual "simple" moves, try Rust.

pingyong 7y ago

I mean requiring an explicitly defaulted move constructor or something to that effect I wouldn't mind, but personally I also think it's beyond obvious that if you move from a smart pointer that it's going to hold a nullptr after that. I wouldn't consider that hard to understand (or surprising) at all compared to something like even relatively simple thread synchronization, something that comes up for pretty much any native developer eventually these days.

DoofusOfDeath 7y ago

Let me start by saying I have tremendous respect for the people who oversee C++'s evolution. It seems like a very difficult challenge, and I believe their intentions are pure. But I agree completely with your point about "move" semantics. Some language rules that seem clear to Sutter et al are insanely complicated to normal C++ developers. Most of us could probably stay on top of C++'s rules if we spent many hours per week on that task. But few of us have the time or interest to do that.

dragontamer 7y ago
"Simple" is an overloaded English term. Its not that "Move is so simple that you should understand it". It seems to be "Move is so simple it doesn't actually get the job done that most people want".

hinkley 7y ago

> still widely misunderstood is basically proof of that. How much better the world would be if software developers started making judgements based on empirical evidence instead of rhetoric and navel gazing... To paraphrase the old bit: If an idiot misuses your software in the morning, you have a user who's an idiot. If idiots misuse your software all day, you're the idiot.

imron 7y ago

> No, they aren't simple and the fact that are still widely misunderstood is basically proof of that. The article disproves itself. Sure, move is simple, if you stick to that one very narrow use case (that still needs std::move() boilerplate around moves to signal intent). The problem (that the article then goes to point out) is that there are so many non-simple and buggy ways move can (and does) get used. So you don't just need to learn the simple use case (with added boilerplate), you also need to learn all the complicated buggy use cases so that you can avoid using them. For actual "simple" moves, try Rust.