What, again? [LWN.net]

What, again?

Posted May 2, 2007 1:58 UTC (Wed) by njs (subscriber, #40338)
In reply to: What, again? by dcoutts
Parent article: The Rise of Functional Languages (Linux Journal)

C++ actually does rather better than this (if used correctly) -- it's easy to use block scoping for most resource management (because, well, most resources of all kinds actually have lexical extent, at least in most programs when written well), and when a resource has dynamic extent, you use a smart pointer, which has explicit semantics about when it will be freed (i.e., exactly when the last reference disappears). Or you can do other fancier and situation-specific things if you want, of course, like pooled allocation.

There's no reason that other languages couldn't do this, but most GC languages are so hasty to ensure that the programmer does not *have* to worry about memory management that they remove the guarantees that the programmer needs in case they ever *want* to worry about memory management. So, in particular, most GC languages have either poor or no support for finalizers (cf. the weird interactions between Python's __del__ and the cycle collector, or the minimal guarantees Java makes about the environment in which a finalizer will be run), and make no promptness guarantees about collection. C++ is very very far from a perfect language, but it does get this part right -- you can always tell from code inspection exactly when each resource will be acquired and released.

(Log in to post comments)

What, again?

Posted May 12, 2007 6:55 UTC (Sat) by jwalden (guest, #41159) [Link]

when a resource has dynamic extent, you use a smart pointer, which has explicit semantics about when it will be freed (i.e., exactly when the last reference disappears).

That's all well and good for simple data, but it falls flat on its face with cyclic data. If your data is cyclic, you have to explicitly break it somehow, perhaps via forget, or else no member of the cycle is going to be deallocated. Consider also that if you do this, you also have to be careful that in breaking the cycle you have a (perhaps stack-allocated) smart pointer to yourself as well, or the action of forgetting may trigger a sequence of forgets which eventually causes the method of the object performing the deletion to delete itself! Smart pointers ease much of the common drudgery, but they are not a panacea.

As for the rest of your comment, it's true that having the ability to perform prompt finalization is useful, in some circumstances; it enables idioms like RAII. I do have to disagree with "you can always tell from code inspection exactly when each resource will be acquired and released", however, because determining variable lifetime (particularly effective lifetime, i.e. how long the value of a variable can influence future execution -- GC provides no solution to that problem) for values on the heap can be reduced to the halting problem.