8 ms·
You can't really accidentally cause memory leaks without being made aware that your code may leak by the compiler and/or docs. The "easiest" way to do it accide
by lblume 2y ago
You can't really accidentally cause memory leaks without being made aware that your code may leak by the compiler and/or docs. The "easiest" way to do it accidentally would be an Rc loop, but that is harder to write than Rc::new_cyclic which gives you the memory-correct Weak reference. When you stick to a fully owned tree memory model (or use bump allocators for fancier data structures) things usually turn out very easy, and I pretty much never had to worry about this.
- demurgos 2y ago> You can't really accidentally cause memory leaks without being made aware that your code may leak by the compiler and/or docs. It's true if you stick to the standard library, but I assume that the Cosmic frameworks adds a layer of complexity. I'm not familiar with their codebase, but I can easily see how an Rc cycle can appear behind a system with lots of shared references (e.g. callbacks, GUI components with backlinks, etc.). You can also get memory leaks through caches without a clear eviction policy. You can also get cases of "memory amplification" where you hold an Rc to a larger struct despite only needing a tiny amount of data from it. Basically, I agree that the standard library tries to steer you away from memory leaks. However, I also understand that it's not foolproof and can see how you can get in a situation with leaks when your approach is to take some tech debt to avoid short-term delays.