3 ms·
C++ is designed to be low overhead. Requiring a moved-from object to take on a newly-constructed state will add overhead that won't be necessary most of the ti
by mark-r 7y ago
C++ is designed to be low overhead. Requiring a moved-from object to take on a newly-constructed state will add overhead that won't be necessary most of the time. If you want to add your own convention you're free to do so, knowing what the downside will be.
- mannykannot 7y agoIndeed, though it should at least go through destruction without undesirable side-effects. In the article, however, Herb Sutter appears to be arguing for something stronger: Q: Does “but unspecified” mean the only safe operation on a moved-from object is to call its destructor? A: No. ... Q: What about objects that aren’t safe to be used normally after being moved from? A: They are buggy...
- mark-r 7y agoSurely he doesn't consider unique_ptr to be buggy, so there must be some subtlety that isn't captured by that statement. Perhaps it's in the definition of "normally" - you can't dereference a moved-from unique_ptr, but you can certainly reassign it to a new pointer and go on to use it from there.
- mannykannot 7y agoI think so, hence my opening sentence. I think it is also fair to say that library-writers generally have less leeway in this matter than application writers, who may know that certain scenarios are not a problem. BTW, I have updated my original post to mention swapping source and destination, another common idiom for satisfying the requirement.