3 ms·

Move constructors can write into overlapping memory while copy constructors cannot, iirc. I thought that compilers would use this distinction to allow for memmo

by qppo 6y ago

Move constructors can write into overlapping memory while copy constructors cannot, iirc. I thought that compilers would use this distinction to allow for memmove instead of memcpy in defaulted move/copy constructors even for POD but I could be wrong.

comex 6y ago
You mean memcpy instead of memmove? I'm pretty sure that all types of constructors expect `this` to be non-aliased, so the compiler could use memcpy for both move and copy constructors. I also checked move and copy assignment operators – is it UB to move-assign an object to itself? Based on this very confusing Stack Overflow thread [1], I think the answer is: no, not at a language level, although it might be bad to do it with standard library types. If that's correct, a compiler-generated default move assignment operator would have to assume aliasing is possible and use memmove, same as with copy assignments. [1] https://stackoverflow.com/questions/13127455/what-does-the-standard-library-guarantee-about-self-move-assignment https://stackoverflow.com/questions/13127455/what-does-the-s...
- qppo 6y ago
  No I meant that the only difference between a move and a copy under the hood is that the compiler can assume the destination memory overlaps the source. If the struct is large that might mean using a memmove instead of memcpy. I don't think aliasing the this pointer matters, since it's the pointed-to memory that could be aliased. But I'm not sure if that's actually faster or if any compiler utilizes the semantic difference.
jdashg 6y ago
For perf, one generally uses memcpy unless memmove's semantics are needed. I think you have confused memcpy vs -move with copy vs move ctors. Certainly your last sentence is not correct for any reasonably written code. Check the docs yourself, but this doesn't match my understanding.

3 ms·

Move constructors can write into overlapping memory while copy constructors cannot, iirc. I thought that compilers would use this distinction to allow for memmo

by qppo 6y ago

comex 6y ago
You mean memcpy instead of memmove? I'm pretty sure that all types of constructors expect `this` to be non-aliased, so the compiler could use memcpy for both move and copy constructors. I also checked move and copy assignment operators – is it UB to move-assign an object to itself? Based on this very confusing Stack Overflow thread [1], I think the answer is: no, not at a language level, although it might be bad to do it with standard library types. If that's correct, a compiler-generated default move assignment operator would have to assume aliasing is possible and use memmove, same as with copy assignments. [1] https://stackoverflow.com/questions/13127455/what-does-the-standard-library-guarantee-about-self-move-assignment https://stackoverflow.com/questions/13127455/what-does-the-s...
- qppo 6y ago
  No I meant that the only difference between a move and a copy under the hood is that the compiler can assume the destination memory overlaps the source. If the struct is large that might mean using a memmove instead of memcpy. I don't think aliasing the this pointer matters, since it's the pointed-to memory that could be aliased. But I'm not sure if that's actually faster or if any compiler utilizes the semantic difference.
jdashg 6y ago
For perf, one generally uses memcpy unless memmove's semantics are needed. I think you have confused memcpy vs -move with copy vs move ctors. Certainly your last sentence is not correct for any reasonably written code. Check the docs yourself, but this doesn't match my understanding.