4 ms·
It may seem inelegant but it pretty cleanly addresses real edge cases in systems-y code where the object necessarily has a shorter lifetime than its associated
by jandrewrogers 1y ago
It may seem inelegant but it pretty cleanly addresses real edge cases in systems-y code where the object necessarily has a shorter lifetime than its associated memory for strict safety.
In these cases, something resembling "use after free" is unavoidable if the move is destructive even though the object is semantically dead. Putting the object in a sentinel state where it is alive but not usable captures the semantics of deferred destruction pretty well.
- nixpulvis 1y agoIn practice it just means a lot of sentinel values and unuseful potential accesses.
- jandrewrogers 1y agoNot really. In the vast majority of cases this is all elided. There is no cost, either in lines of code or runtime. When you are decoupling memory lifetimes from object lifetimes it is pretty explicit. It isn't like this sneaks into your code on its own. You have to manage the implications of it yourself.
- nixpulvis 1y agoIt's not about cost of correct code, it's about accidental wrong code.
- jandrewrogers 1y agoThat’s really not a thing. By default it is correct, you have to go out of your way to make it incorrect.
- nixpulvis 1y agoIt's actually really easy... std::vector<int> a = {1,2,3}; // Added this without thinking about future uses of a. std::vector<int> b = std::move(a); use_vec(b); // ... use_vec(a);