3 ms·

Ah, the copying part, yes - but then again if I'm doing that, I'd expect to be doing so in order to access A at which point I already needed that bit of memory.

by mst 15y ago

Ah, the copying part, yes - but then again if I'm doing that, I'd expect to be doing so in order to access A at which point I already needed that bit of memory. The collection thing I can definitely see though. One thing I've never quite worked out is - without reference counting, how do you handle timely destruction? I know that if I do something like: { my $x = foo(); ... } then $x will be destroyed at the exact point the } is hit, or that an exception unwinds the stack past this point. That lets me do all sorts of nice things like rolling back a transaction automatically, throwing a warning if some task was expected to be completed but hasn't been, and other bits and pieces. In a mark-and-sweep GC language, presumably there's some other additional feature that needs to be implemented in order to provide this?

kmontrose 15y ago
Well, there are certainly cases where you grab a reference speculatively; anything where you need > N in a collection to act on, for instance, but don't know how many items there are yet (such as when you're reading from a stream). There's also the "early return" case, where you'd grab reference say A, B, and C but only dereference C in code that runs if A and B failed some condition. The equivalent to timely destruction in C# is a using statement combined with implementing IDisposable. using(var stream = File.Open(somePath)) { // use stream to do whatever } This is syntactic sugar for a try{ } finally { } (that also exists in Java) that calls Dispose() in finally. You do any cleanup you need to in Dispose(), things like releasing file handles. The only way to dodge that Dispose() is to tear the execution thread down, which generally means the process is gone with it. C# classes (but not structs) can also declare destructors, but their execution schedule isn't guaranteed; they're useful for making absolutely sure resources are released eventually, Dispose() is preferred for timing and performance.

by mst 15y ago

kmontrose 15y ago

Well, there are certainly cases where you grab a reference speculatively; anything where you need > N in a collection to act on, for instance, but don't know how many items there are yet (such as when you're reading from a stream). There's also the "early return" case, where you'd grab reference say A, B, and C but only dereference C in code that runs if A and B failed some condition. The equivalent to timely destruction in C# is a using statement combined with implementing IDisposable. using(var stream = File.Open(somePath)) { // use stream to do whatever } This is syntactic sugar for a try{ } finally { } (that also exists in Java) that calls Dispose() in finally. You do any cleanup you need to in Dispose(), things like releasing file handles. The only way to dodge that Dispose() is to tear the execution thread down, which generally means the process is gone with it. C# classes (but not structs) can also declare destructors, but their execution schedule isn't guaranteed; they're useful for making absolutely sure resources are released eventually, Dispose() is preferred for timing and performance.