The A-Z of programming languages: C++

Bjarne Stroustrup of C++ fame dissects the history of his famed programming language

1 2 3 4 5 6 Page 6
Page 6 of 6

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.

Finally, is there anything else you'd like to add?

Yes, I think we ought to consider the articulation of ideas and education. I have touched upon those topics a couple of times above, but the problems of getting people to understand what C++ was supposed to be and how to use it well were at least as difficult and time consuming as designing and implementing it. It is pointless to do good technical work and then not tell people about it. By themselves, language features are sterile and boring; to be useful, programmers have to learn how language features can be used in combination to serve some ideal of programming, such as object-oriented programming and generic programming.

I have, of course, written many purely technical papers, but much of my writing have been aimed at raising the level abstraction of programs, to improve the quality of code, and to give people an understanding of what works and why. Asking programmers to do something without giving a reason is treating them like small children -- they ought to be offended by that. The editions of The C++ Programming Language, D&E, "Teaching Standard C++ as a New Language" and my HOPL papers, are among my attempts to articulate my ideals for C++ and to help the C++ community mature. Of course, that has been only partially successful -- there is still much "cut and paste programming" being done and no shortage of poor C++ code -- but I am encourage by the amount of good code and the number of quality systems produced.

Lately, I have moved from industry to academia and now see the education problems from a different angle. We need to improve the education of our software developers. Over the last three years, I have developed a new course for freshmen (first-year students, often first-time programmers). This has given me the opportunity to address an audience I have never before known well and the result is a beginner's textbook Programming: Principles and Practice Using C++, which will be available in October.

This story, "The A-Z of programming languages: C++" was originally published by Computerworld Australia.

Copyright © 2008 IDG Communications, Inc.

1 2 3 4 5 6 Page 6
Page 6 of 6
Shop Tech Products at Amazon