Consider a Movable file handle.
File fh = File(fopen("file.txt"));
foo(std::move(fh));
Using fh after foo() would yield a compile error in Rust. It does not in C++.
File fh = File(fopen("file.txt"));
foo(std::move(fh));
Using fh after foo() would yield a compile error in Rust. It does not in C++.
An object should be accessible for reassigning a value after its move, as its often needed for algorithms, thats exactly why the C++ Standard mandates this. Move does really only make sense if the class holds a moveable allocation, such as a container, array etc., which makes copying expensive.
The same is true in Rust. A moved-from value can be reassigned, but cannot be used (compile enforced) until it is reassigned. :)
Usually with high rotation of developers coming and going, since parts of the project tend to be delegated to be other companies, many times with developers that aren't all at the same skill level.
When you work at this scale, memory errors and misuse of resource are quite common.
No developer is able to have the whole code on his/her head and sometimes also does not have the time to understand the whole codebase.
So mistakes happen quite often.
This is why C got out of love in the enterprise or why companies like Google and JPL have such strict C++ design guide.