3 ms·
I actually don't really think about memory all that much for most of the kinds of work that I do. RAII kinda just does it. His idea for optional GC for some d
by VWWHFSfQ 3y ago
I actually don't really think about memory all that much for most of the kinds of work that I do. RAII kinda just does it. His idea for optional GC for some data and manual memory management for other data is kinda interesting though.
- cmrdporcupine 3y agoIt's not an advanced or particularly well optimized GC, but that's effectively what Arc<> or Rc<> is getting you in Rust (or shared_ptr in C++ etc).
- candiddevmike 3y ago> His idea for optional GC for some data and manual memory management for other data is kinda interesting though. Most GC languages (Java, C#, Go) have the concept of memory arenas: manually managed memory allocations. Seems like what you're looking for, though not native to Rust.
- api 3y agoYou do have to think about memory a little bit in Rust with RAII, but not much. There are two situations: First there are cyclic data structures. For these you have to be sure to use a construct like weak reference counting pointers for things that are self referential or you will leak memory. Either that or you store links by object ID instead of pointer. The former adds a bit of cognitive overhead and the latter adds runtime overhead. The second case is high performance code where you want to avoid allocating memory in an inner loop. The second case comes up a bit in GC languages too though, since if you allocate without thinking you can easily write code that balloons the heap and forces the garbage collector to constantly invoke and do a lot of work to collect temporary objects. The code will work but will be slow and allocate more heap than needed. Edit: actually embedded is a third situation where you might have to think a lot but that’s true for any language you are using.