@eliduvid
I'm a rust dev and I agree with the dude. the problem is, you may not have cheap move option at all as a user of an object even if you want to. this is different from just being safe by default
@Heater-v1.0.0
I moved from objects in C++ five years ago. Now all my objects are in Rust. :)
@kekstee1
I've found static analyzers to consider moved from objects uninitialized anyway and also think it's way easier to implement objects to behave like that. So yeah I think the standard is in a horrible place wrt move guarantees.
@CartoType
I recently had a bug where I was calling a function on a moved-from object. I benefited from the fact that there was no undefined behaviour and the function returned a sensible (but unexpected by me) result. So Iām quite happy with move semantics that mandates that moved-from objects can support operations other than assign or destroy, because it makes debugging easier. Of course it would be even easier if the compiler had told me that I was accessing a moved-from object, but that feature was not provided by the development system I was using, which was Xcode.
@KarelDonk
always a pleasure to listen to kalb
@howardhinnant
Self move assignment should be safe in the sense that it does not cause a crash or put the object into an invalid state. Self move assignment need not be a no-op like self copy assignment (though it can be). swap(x, x) will perform a self-move-assignment on x, and the self-swap will not modify x even if x's self-move-assignment modifies the value of x.
@brunomarques309
š I might be missing something here, but let's say that the standard committee retro-pedals on this decision, and clearly states that an object that was moved from can only be assigned to or destroyed, can't we then make it an error, at compile time, to read from an partially formed object, like it is done in cough cough Rust cough , without compromising on performance? I'm not an expert but it seems to me that this what gets most people criticizing C++ in terms of language safety
@benhetland576
Regarding the example of appending to a moved-from vector and the rule of only assigning to or destructing a moved-from object. There are some other kind of methods too that have the trait that they effectively "reset" the object into a fresh defined state, just like a constructor or assignment operator is expected to do. In the std::vector's case this is in particular the clear() method. Should it be safe to call as well? It would certainly make sense. Here, of course, it would mess with the requirement that the vector's capacity is to remain unchanged after clear. To change that requirement could have undesired or unexpected results, so one could "shoehorn in" an extra allocate to the old capacity to make everyone happy. Now we would be on a slippery slope as to what should remain somewhat valid even after moved-from (here: the value of the capacity setting). This already happens -- typically for pointer members -- though.
@howardhinnant
Two out of three implementations of std::list have a noexcept move constructor. I'd be in favor of standardizing that. But good luck on convincing the third implementor.
@mishadjukic8904
@28:45 and @30:14 āunspecified but valid state ā¦. defining valid as supporting any operation that has no preconditionā How is āsupportingā defined? In the example, if .size() would return 10 (although the pointer is nullptr), can we say that the operation is supported, but its result is āunspecifiedā, or something like that š On the other hand, accessing first element does have a preconditionā¦ Indeed, that precondition would be formally satisfied because .size returns >= 1 (10 in particular), but the operation still does have precondition, so it does not fall into category of operations that need to be āsupportedā. Does this reasoning have a traction? š
@SillyRabitThatsFent
1:03:22 serialize before, then move, then serialize the moved to object, then compare the serializations, then check that it can be destructed.
@iuiui-iuiui
1:03:35 "should we have move-sanitizer?" clang-tidy does a pretty good job of warning about moved out objects.
@AlfredoCorrea
12:22 under the logic of this presentation (which I agree with), I have a question: should have containers have left its elements uninitialized when possible? e.g. std::vector<T>(5) would create 5 partially formed elements while std::vector<T>(5, {}) creates 5 initialized elements. (I think so)
@peregrin71
For me move semantics is also about modeling "ownership". "auto foo(Widget&& w)" also indicates that you as a caller transfer ownership of `w` to foo and that the caller should no longer do anything with "w" after this call. Except indeed deleting it or reusing its memory by assigning a new value to it (and the last option IMO is a perfmance optimziation and optimization always comes with a higher level of cognitive load). Pass by reference in that respect is IMO totally different, since the caller is the one that will have the ownership during and after the call (the callee can only make copies if some kind of persistency is needed). So yes I agree moved from objects must behave like "unitialized variables" (and that means reading from them or calling operations on them should be UB)
@AdrianMNegreanu
using the mantra "because this is c++" won't help much
@marius1768
I don't understand the "cognitive load" part at all. It is so much easier (for me at least) to accept moved-from object as no longer usable, unitialized-like, that i cannot find even a use for the opposite case. It simplifies implementation, it simplifies the analysis of what is happening in the code ..
@sneeddeens9895
I still don't get it why even go to such direction. 1.) To preserve invariant? To make people write "well-behaved" types, as Herb Sutter says. Even in expenses of some counter examples, like with std::list? 2.) For less burden on standard library implementers? (Somehow, I don't get this) 3.) So it would be easier to educate people on move semantics? Even though as Jon says, there is simple rule: "don't use moved-from objects other than assignment and destruction". I quite lost in history of this issue, but I definitely leaning more on Jon's side.
@sagarverma13
@40:12 then how we can write a unit test to check the state like isEmpty and getCapacity of moved-from object? In my custom class of FixedMemoryList, I already assigned nodes to invalid (i.e., -1) and also set the size to 0 in my class move constructor. Then can I call isEmpty and getCapacity methods on moved-from object in a unit test logic?
@rafasomla4808
How about calling clear() on moved-from vector? If we except argument of this talk that would not be allowed which feels wrong.
@letsbegin_staytrue