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.
Removed by mod
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)
Removed by mod
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.
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.