3 ms·
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 m
by 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 agoNo 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.