49:26 just in case anyone is wondering, this is not UB: C++ member initialization is done based on the order in which they're declared in the class, not the initialization list order. However, this is extremely confusing to not have them line up, so don't do it IRL (lest you confuse colleagues).
48:48 it's not clear from your explanation, but initialization order is always the order of the data members in the class definition. The order in each constructor is ignored. So this code is perfectly fine, it's just confusing to read. The only warnings would be a suggestion to re-order the constructor initializer list so it matches the actual behavior, but either way the behavior is the same and, in this case, well-defined.
55:51 the topic of self-move is a little controversial- many experts say it’s OK for self-move to change/clear the object state, and the only requirement is that the object is left in a valid state.
Notice that in Version 5 on the last minutes, you can leave the same class definition the same and init the Algorithm directly by a Configuration, no need for the user to explicitly constrcut AlgorithmInit from it. Why? Because of C++ can automatically convert Configuration->AlgorithmInit.
For me the object that was moved from is a no-go for any use. If you use it, you are doing something wrong. To waste time and to try to safeguard against purposefully bad code is useless, that's akin to trying to guard against your object being memcopied with 0 bytes or something like that. Of course, you can do that, but why would you?
