2 ms·
That's not a lifetime problem. The object is still appropriately alive if referenced. The lifetime in the GC and free sense simply means that while an object re
by zbobet2012 10y ago
That's not a lifetime problem. The object is still appropriately alive if referenced. The lifetime in the GC and free sense simply means that while an object reference exists it should be valid. See http://web.media.mit.edu/~lieber/Lieberary/GC/Realtime/Realtime.html http://web.media.mit.edu/~lieber/Lieberary/GC/Realtime/Realt... for example.
GC doesn't guarantee you won't have resource leaks (of which memory is one). It guarantees that when you no longer reference an object it will be freed and that while you have a reference its valid. That's the lifetime problem. The Rust docs call it the same thing for that matter...
- jononor 10y agoMaybe not strictly lifetime problem, but the unexpectedly extended lifetime can cause problem. The caller switches which object it is working on and now the live object in the library is disconnected. Or, if it is mutable, changes could be done by the library at a time which break caller expectations. I've found that in GC'ed languages (like Python or JavaScript) not taking care of "lifetime", easily results in logic bugs. Better than crashes* - but still problematic. * Maybe not always better either. Not crashing may lead to silent data corruption. And obvious problems (like crash) tend to be fixed faster than subtle ones, in practice.