"No way to prevent this", say programmers of only language where this regularly happens
Conversation
No limit on the kind of data structures you can write in Rust. You may have to write a small amount of unsafe code.
1
6
Or accept using reference counting and dynamic mutability checks. Thread local reference counting is quite cheap, especially with default move semantics rather than implicitly adding new owners. People greatly exaggerate how often Rc/Weak and RefCell aren't a viable option.
1
2
This Tweet was deleted by the Tweet author. Learn more
I don't understand what your reply has to do with my tweet. It applies to other architectures. The implication that I have an x86 centric perspective is quite wrong considering that I work full time with AArch64 targets. I only deal with x86_64 as a secondary thing or not at all.
This Tweet was deleted by the Tweet author. Learn more
The overhead isn't significantly larger on embedded. Rc<T> is quite cheap everywhere. It's thread-local and uses non-atomic counters. It adds 2 words to the allocation (one for weak pointers). There's no implicit reference counting like C++. Owning references are moved around.
There's only counting overhead when clone() is explicitly called. For each time clone is called, it will do a non-atomic increment, and then when that extra owning reference goes out of scope it will do a non-atomic decrement and branch to check if it should be freed. It's cheap.
1
It's not the same thing as shared_ptr in C++ which is far more heavyweight. That has more complexity, often makes multiple allocations, needs to use atomic operations to make it thread safe and has implicit reference counting which ends up being very pervasive rather than rare.
1
2
Show replies