7 ms·
And the most important idea: destructive moves. Since C++ doesn't track lifetimes it has to leave the object in a "valid state" after a move and the destructor
by sprocketz 15d ago
And the most important idea: destructive moves.
Since C++ doesn't track lifetimes it has to leave the object in a "valid state" after a move and the destructor still runs which has to have a check if it should do something or not.
- pornel 15d agoBTW, Rust's lifetime annotations for borrowed references are a mostly orthogonal feature. Liveness of objects for move/drop semantics is tracked differently, without any syntax and with implicit runtime drop flags where necessary. C++ could probably add the same deinitialized/moved-from state tracking (with an opt-in for back compat sake) purely to avoid dtor bloat, without having to add safety of borrow checking.
- bluGill 15d ago> C++ could probably add the same deinitialized/moved-from state (with an opt-in for back compat sake) purely to avoid dtor bloat, without having to add safety of borrow checking. There is a lot of talk in the C++ committee about this. The details are complex in some obscure cases.
- account42 13d agoAt the very leas you'd also need to fix the caller-destructed ABI mess to get a 100% solution.
- siramikvarze 13d ago[dead]
- jandrewrogers 15d agoWhile not the common case, C++ move semantics match the situation in systems code where correctness requires decoupling logical object lifetimes and destructors. The object is logically dead but the destructor may be deferred indefinitely for safety reasons. Most code doesn't have the shared memory setups where deferred destruction is necessary.
- gruntled-worker 13d agoBut the compiler won't necessarily generate any code for the destructor: https://godbolt.org/z/PMando5x4 https://godbolt.org/z/PMando5x4