I am currently working on a custom allocator in c++. This allocator has to defragment its memory on a regular basis, by shifting the memory and objects around. These shifts are always downward, meaning that the address of a moved memory chunk always decreases when it gets moved. There is no problem doing so when the old memory chunk and the new memory chunk don't overlap. If they are overlapping I first must move the object into a temporary area outside of the allocator memory and then move it back to the new memory chunk.
If std::is_trivially_move_constructible is true for the moved type, then I might save this extra move to a temporary memory chunk if the order of assignments inside a default move constructor is well defined. This leads to my question: Is the order of assignments well defined or is it platform specific?
From the standard (Section 15.8.1 [class.copy.ctor])
(14) The implicitly-defined copy/move constructor for a non-union class X performs a memberwise copy/move of its bases and members. [ Note: Default member initializers of non-static data members are ignored. See also the example in 15.6.2. — end note ] The order of initialization is the same as the order of initialization of bases and members in a user-defined constructor (see 15.6.2)
Following the link leads us to Section 15.6.2 [class.base.init]
(13.3) Then, non-static data members are initialized in the order they were declared in the class definition (again regardless of the order of the mem-initializer s)
Not quite answering the question to the point, but as Igor Tandetnik also said in his answer, it is legal to transform a trivial constructor into a std::memmove