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?
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.
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).
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.
I like this dude. Soft-spoken, calm, evenly paced.
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?
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.
Yes I could have done a better job there. Thanks for the comment and proper explanation!
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).
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.
15:10 on the left, I think b is a function declaration due to most vexing parse, instead you'd have to write auto b = Zaphod();
Yes! You're right, I should have seen that one. Thanks for the heads-up!
Thank you for this great talk
You are so very welcome! Thank you for your comment.
@@cpponsea such an unexpectedly warm response, thank you so much, made my day
Thank you very much!