31.9. RVL: The Big Win for Garbage Collection

As someone who likes to have a modest mastery of several languages and can see the virtue in most of them,^[14] one thing that dumbfounds me in the debate between languages that use garbage collection and those that do not is that the arguments for garbage collection are that it relieves the programmer from clearing up their own memory, or saves them from making the mistake of forgetting to release their memory. Politeness (and my editor) prevents me from saying what I really think about this argument, so I'll just say I think it's utter nonsense.

^[14] I can see no virtue in Visual Basic, and never have. Sorry.

The first thing is, with C++ this is almost always a nonissue. If you are sensible, then you use RAII (see Chapters 3, 4, and 6), and therefore the problem largely disappears.

The second part of this that really irritates me is that proponents of such languages as, say, Java and .NET, always carp on about memory leaks, as if memory is the only kind of resource that can be leaked. At least as serious are leaks of other kinds of system resources, such as file handles, synchronization objects, and the like. The amazing thing is that these languages provide virtually no support for the automatic and exception-safe handling of such resources. One is left with a stinking big mess of try-finally blocks. Hideous stuff!

The irony is that these proponents never use the real issue in which garbage collection is indeed incontestably superior. When using garbage collection, the problems of RVL, as discussed in this chapter and in sections 16.2 and 20.6.1, simply disappear. Since garbage collection works by releasing memory only when there are no references to it in active code, it is axiomatic that a pointer to a heap-allocated memory block cannot be invalid while it is still needed. All we would need would be to return a new heap block containing the converted form. If there were efficiency issues with that, we could maintain a special memory pool of twenty-one-character^[15] heap blocks, which would be efficiently given out to the conversion functions for each conversion.

^[15] The maximum number of characters in any 64-bit number is 20 (assuming no thousands-separator, or similar localization effects).