How do you recommend people handle memory management in C++?

My recommendation is to see memory as just one resource among many (e.g. thread handles, locks, file handles, end sockets) and to represent every resource as an object of some class. For example, memory may be used to hold elements of a container or characters of a string, so we should use types such as vector rather than messing around with low-level data structures (e.g. an array of pointers to zero-terminated arrays) and explicit memory management (e.g., new and delete). Here, both vector and string can be seen as resource handles that automatically manages the resource that are their elements.

Wherever possible, I recommend the use of such "resource handles" simply as scoped variables. In that case, there is no explicit memory management that a programmer can get wrong. When an object's lifetime cannot easily be scoped, I recommend some other simple scheme, such as use of "smart" pointers (appropriate ones provided in C++0x) or representing ownership as membership in some collection (that technique can be used in embedded systems with Draconian time and space requirements). These techniques have the virtues of applying uniformly to all kinds of resources and integrating nicely with a range of error-handling approaches.

Only where such approaches become unmanageable - such as for a system without a definite resource management or error handling architecture or for a system littered with explicit allocation operations - would I apply GC. Unfortunately, such systems are very common, so I consider this is a very strong case for GC even though GC doesn't integrate cleanly with general resource management (don't even think of finalizes). Also, if a collector can be instrumented to report what garbage it finds, it becomes an excellent leak detector.

When you use scoped resource management and containers, comparatively little garbage is generated and GC becomes very fast. Such concerns are behind my claim that "C++ is my favorite garbage collected language because it generates so little garbage."

I had hoped that a garbage collector which could be optionally enabled would be part of C++0x, but there were enough technical problems that I have to make do with just a detailed specification of how such a collector integrates with the rest of the language, if provided. As is the case with essentially all C++0x features, an experimental implementation exists.

There are many aspects of garbage collection beyond what I mention here, but after all, this is an interview, not a textbook.

On a less serious note, do you think that facial hair is related to the success of programming languages?

I guess that if we look at it philosophically everything is related somehow, but in this case we have just humor and the fashion of the times. An earlier generation of designers of successful languages was beardless: Backus (Fortran), Hopper (COBOL), and McCarthy (Lisp), as were Dahl and Nygaard (Simula and Object-Oriented Programming). In my case, I'm just pragmatic: While I was living in colder climates (Denmark, England, and New Jersey), I wore a beard; now I live in a very hot place, Texas, and choose not to suffer under a beard. Interestingly, the photo they use to illustrate an intermediate stage of my beard does no such thing. It shows me visiting Norway and reverting to cold-weather type for a few days. Maybe there are other interesting correlations? Maybe there is one between designer height and language success? Maybe there is a collation between language success and appreciation of Monty Python? Someone could have fun doing a bit of research on this.