4 ms·

Problems involving memory deallocation in the GC applications I've written seem to happen infrequently, certainly infrequently enough that it is one of the lowe

Problems involving memory deallocation in the GC applications I've written seem to happen infrequently, certainly infrequently enough that it is one of the lowest items on my list of things I'd like to fix that cause problems in development. > but you can still run into logic errors when part of your code assumes that it's done dealing with a piece of data and another part has a different idea. Mostly I think this is sufficiently handled by not mutating shared state as a practice. However, since Rust has mutable borrows, it seems to me that you're still in danger of running into this.

vertex-four 10y ago
Mutable borrows are not shared - you can't touch the data elsewhere while it's borrowed mutably, and you can't get a mutable borrow while there's immutable borrows. Shared state is unfortunately a common affliction on large codebases, and if the language supports and even encourages it, it can be difficult to prevent it from happening as the codebase grows and customers want features that don't fit into the architecture wonderfully.
int_19h 10y ago
In higher-level languages, object lifetime is more than just whether the memory is there or not; it's also about whether the usual invariants apply. For example, in C#, you need to Dispose() objects that are logically no longer used, to have them properly cleaned up. Using an object after it's disposed typically results in an ObjectDisposedException. This isn't as bad as a segfault, but ultimately it's still a crashing bug in the app - and solving it requires figuring out who needs to call Dispose when - i.e. figuring out the lifetime.