This is 14 years old by now - hardly “modern”. RAII itself is even older.
100% agree. But I like posting articles like these because it brings me back to how I learned programming, and Linux specifically - namely by reading a bunch of articles from similar link aggregators and sharing sites.
My hope is that sharing articles like these is a form of planting the seeds for another cycle for people to learn the way that I did.
What I find interesting is that move semantics silently add something to C++ that did not exist before: invalid objects.
Before, if you created an object, you could design it so that it kept all invariants until it was destroyed. I’d even argue that it is the true core of OOP that you get data structures with guaranteed invariants - a vector or hash map or binary heap never ceases to guarantee its invariants.
But now, you can construct complex objects and then move their data away with std::move() .
What happens with the invariants of these objects?
According to cppreference:
Unless otherwise specified, all standard library objects that have been moved from are placed in a “valid but unspecified state”, meaning the object’s class invariants hold (so functions without preconditions, such as the assignment operator, can be safely used on the object after it was moved from)
I would expect this to be true of all types. An easy way to do this is to null an internal pointer, set an internal fd to a sentinel, etc and check for that when needed, but this could be an easy source of errors if someone’s not paying attention.
Ideally it would be statically checked if a value is used after being moved, but that’s just my Rust brain speaking.
Depends on the object what happens when they are moved from. Some objects are put into a valid moved from state (usually depends on if doing so is free or required anyway. For example to satisfy the invariant of the moved to unique pointer the moved from pointer needs to be set to nullptr in order to prevent the moved tos unique pointer being deleted from underneath it)
So what do you do with a file object?
Douno off the top of my head. To take a wild guess they might just wrap a file handle and give it s nice api? If that’s what they do then moving from the file zeros out he handle for basically the same reason smart pointers set their internal pointer to nullptr, so they don’t delete it (or close the file in this case) underneath the new object.