Modified April 27, 200
These are questions that people ask me often. If you have better questions or comments on the answers, feel free to email me bs@research.att.com. Please remember that I can't spend all of my time improving my homepages.
This page concentrates on personal opinions and general questions related to philosophy. For questions that more directly relate to C++ language features and the use of C++, see my C++ style and technique FAQ. For C++ terminology and concepts, see my C++ glossary. For links to useful sources of C++ information, see my C++ page. For information about my books (incl. reviews and support information), see my book list. For papers and ISBNs for translations of my books, see my publication list.
Some of my FAQ has been translated into Chinese; see here (traditional) or here.
For people who can't receive sound, here is a suggestion: Both of my names are pronounced with two syllables: Bjar-ne Strou-strup. Neither the B nor the J in my first name are stressed and the NE is rather weak so maybe Be-ar-neh or By-ar-ne would give an idea. The first U in my second name really should have been a V making the first syllable end far down the throat: Strov-strup. The second U is a bit like the OO in OOP, but still short; maybe Strov-stroop will give an idea.
Yes, this probably is the most frequently asked question :-)
P.S. My first name is Bjarne - not Bjorn (not a name), Bjørn (a related but different name), nor Barney (an unrelated name). My second name is Stroustrup - not Stroustroup, Stroustrop, Strustrup, Strustrop, Strustroup, Straustrup, nor Straustroup (documents using each of these misspellings can be found using google).
Here are links to
Also, if you mail me, please try to make sure that I can reply to you. I really hate it when I have written and sent a reply, just to find that the return address is invalid or inaccessible. This happens to me every week.
Two kinds of messages have a relatively high chance of getting lost: homework questions and questions of the form "how do I use this proprietary library?". I'm a bit sad about not answering the latter questions because often the person asking doesn't understand that the DOS, Windows, or whatever interface from C++ is not part of the C++ standard (and I cannot keep up with the huge number of C++ libraries). If you fail to receive an answer, please consider if your question was of one of these kinds.
What looks "cool and modern" to someone is often considered bad taste by someone else, and fashions change fast. Also, very plain html downloads and displays faster than anything else, and many people still suffer from slow web connections.
See a note about the structure, contents, and aims of "The C++ Programming Language (3rd edition)": The book is aimed at programmers with some experience and a wish to master C++. It is not aimed at non-programmers trying to learn their first programming language or casual programmers trying to gain a superficial understanding of C++ as fast as possible. Consequently, this book focuses on concepts and techniques and goes to some pain to be complete and precise.
If you want to know why C++ is the way it is, have a look at The Design and Evolution of C++ (D&E). Understanding the design criteria and constraints helps writing better programs.
Have a look at the ACCU (The Association of C and C++ Users) site. This is one of the best sites for book recommendations by experienced programmers who are not afraid to speak their mind (booksellers tend to give rosy reviews, and reviews of the form "This book is perfect, I love it, I have read almost three chapters, and can't wait to read more" are worse than useless - why anyone would take advice on how to learn C++ from someone who completely lacks C++ experience beats me). The ACCU rates books for level of experience required and overall quality.
On the other hand, if you want to be fully comfortable with all the major C++ language constructs, with data abstraction, Object-Oriented programming, generic programming, Object-Oriented design, etc., you can easily spend a year or two - if you aren't already acquainted with those techniques.
Is that then the time it takes to learn C++? Maybe, but then again, that is the timescale we have to consider to become better designers and programmers. If a dramatic change of the way we work and think about building systems isn't our aim, then why bother to learn a new language? Compared to the time required to learn to play the piano well or to become fluent in a foreign (natural) language, learning a new and different programming language and programming style is easy.
For more observations about learning C++ see D&E or a note from comp.lang.c++ that I wrote some time ago.
See Learning Standard C++ as a New Language for a discussion of the choice of C++ constructs, techniques, and libraries for early learning. For an example of a book that takes that approach systematically, see Koenig&Moo: "Accelerated C++" from Addison Wesley's C++ In Depth series.
You'll need a textbook for learning C++. This is the case even when your implementation comes with ample on-line documentation. The reason is that language and library documentation together with sample code are not good teachers of concepts. Typically such sources are silent about why things are the way they are and what benefits you can expect (and which you shouldn't expect) from a technique. Focus on concepts and techniques rather than language-technical details.
When choosing a book, look for one that presents Standard C++ and use the standard library facilities in an integrated manner from the start. For example, reading a string from input should look something like
string s; // Standard C++ style cin >> s;and not like this
char s[MAX]; /* Standard C style */
scanf("%s",s);
Look for book recommendations from programmers with solid C++ experience.
Remember that
no one book is the best for everyone.
Have a look at the
book reviews
on the ACCU (The Association of C and C++ Users) site.
Aim to write idiomatic C++: avoid simply writing code in the style of your previous language using C++ syntax; there is little to be gained from simply changing syntax. See Learning Standard C++ as a New Language a discussion of how one might approach C++.
Also, no, I will not suggest "a good project for a student to work on". My experience is that learning enough about a student and his/her course to know what level of difficulty is required and what kind of project is of interst takes time. To think of a good project is then non-trivial, and to explain exactly what the project is and how to approach it can take several messages and several hours. I just don't have that kind of time. Remember, these request come at least weekly. Finally, some students seem to have the idea that if I suggest a project, I am morally obliged to provide quite detailed help in its completion.
Ideas: Look at the exercises in TC++PL3 or other good textbooks. Many of those exercises are designed to keep a student busy for several days, and reading those exercises can inspire an enterprising student to so something similar. Or look at the non-computer-science part of your world: Maybe a biology project couldn use support for a new measurement device or a friend studying history could use an improved database interface. Many of the best projects and the best uses of computers are outside traditional computer science.
See also my C++ style and techniques FAQ. Real novices facing their first "read some data, do something to it, and produce some output" exercise might be interested in a very simple program or a program reading a string from input.
This is the language and standard library described in The C++ Programming Language (3rd edition). The C++ compiler and library suppliers are already shipping implementations that are quite close to the draft standard.
The C++ standard (ISO/IEC 14882) is available for downloading at the National Committee for Information Technology Standards Electronic Store. The cost is (as I write this) US$18.00 payable on-line via credit card. The downloaded document is in PDF form, about 3Mb total size.
The draft standard as it were in later stages of the standards process can be downloaded for free.
Be warned that the standard is not a tutorial; even expert programmers will do better learning about C++ and new C++ features from a textbook.
Most of the features I dislike from a language-design perspective are part of the C subset of C++ and couldn't be removed without doing harm to programmers working under real-world conditions. C++'s C compatibility was a key language design decision rather than a marketing gimmick. Compatibility has been difficult to achieve and maintain, but real benefits to real programmers resulted, and still result today. By now, C++ has features that allows a programmer to refrain from using the most troublesome C features. For example, standard library containers such as vector, list, map, and string can be used to avoid most tricky low-level pointer manipulation.
My personal view is that the key principles should be
I briefly presented some of my ideas at a panel at SD2001w and in slightly greater detail in a keynote at the Spring 2002 ACCU conference. See also, my rules of thumb for The Design of C++0x.
For a variety of reasons, the planned replacement ("ARM++") describing ISO Standard C++ was never written. As the work on C++0x is now proceeding, it is too late for an ARM++ based on ISO C++ 1998.
For 2000 printings - including the hardcover "special edition" - I have two new appendices on Locales and Standard-Library Exception Safety.
The German translation of the "Special Edition" is referred to as the 4th edition.
Seriously, the difference between the current printings of the special edition and the 3rd edition is just the hard cover (and the price difference implied by that stronger cover).
If I were a C++ programmer who hadn't read The C++ Programming Language (3rd Edition), I'd buy and read either the 3rd edition or the special edition. If I used my textbooks and references heavily, I'd choose the hard cover. The cover on the 3rd is the best soft cover available, but it doesn't equal the special edition's hard cover.
If I already had the 3rd edition, I'd buy the SE if my current copy were fraying or if my copy were an early printing (the 3rd now has about 20 printings and SE about 10).
Compared to the first printing, the special edition and the most recent printings of the 3rd edition have 1,000+ corrections and clarifications. As a heavy C++ user, I find that significant. There are also the two new appendices (just over 100 pages; available for download: Locales and Standard-Library Exception Safety).
Existing material has not moved around so page numbers can be used to refer to material in old printings, new printings of the 3rd edition, and in the SE.
The SE also has an improved index.
Also, I don't sell books; I just write them.
And no, there is no free machine readable copy of any of my books
For an incomplete list of C++ implementations, see my C++ compilers list.
Also, where possible, prefer the standard library to non-standard "foundation libraries" and try to minimize use of proprietary extensions.
Much of the relative simplicity of Java is - like for most new languages - partly an illusion and partly a function of its incompleteness. As time passes, Java will grow significantly in size and complexity. It will double or triple in size and grow implementation-dependent extensions or libraries. That is the way every commercially successful language has developed. Just look at any language you consider successful on a large scale. I know of no exceptions, and there are good reasons for this phenomenon. [I wrote this before 2000; now see a preview of Java 1.5.]
Java isn't platform independent; it is a platform. Like Windows, it is a proprietary commercial platform. That is, you can write programs for Windows/Intel or Java/JVM, and in each case you are writing code for a platform owned by a single corporation and tweaked for the commercial benefit of that corporation. It has been pointed out that you can write programs in any language for the JVM and associated operating systems facilities. However, the JVM, etc., are heavily biased in favor of Java. It is nowhere near being a general reasonably language-neutral VM/OS.
Personally, I'll stick to reasonably portable C++ for most of the kind of work I think most about and use a variety of languages for the rest.
If you want to write exclusively for the .Net platform, C# isn't the worst alternative, but remember that C++ is a strongly supported - though less strongly hyped - alternative on that platform.
"Several reviewers asked me to compare C++ to other languages. This I have decided against doing. Thereby, I have reaffirmed a long-standing and strongly held view: Language comparisons are rarely meaningful and even less often fair. A good comparison of major programming languages requires more effort than most people are willing to spend, experience in a wide range of application areas, a rigid maintenance of a detached and impartial point of view, and a sense of fairness. I do not have the time, and as the designer of C++, my impartiality would never be fully credible.
I also worry about a phenomenon I have repeatedly observed in honest attempts at language comparisons. The authors try hard to be impartial, but are hopelessly biased by focusing on a single application, a single style of programming, or a single culture among programmers. Worse, when one language is significantly better known than others, a subtle shift in perspective occurs: Flaws in the well-known language are deemed minor and simple workarounds are presented, whereas similar flaws in other languages are deemed fundamental. Often, the workarounds commonly used in the less-well-known languages are simply unknown to the people doing the comparison or deemed unsatisfactory because they would be unworkable in the more familiar language.
Similarly, information about the well-known language tends to be completely up-to-date, whereas for the less-known language, the authors rely on several-year-old information. For languages that are worth comparing, a comparison of language X as defined three years ago vs. language Y as it appears in the latest experimental implementation is neither fair nor informative. Thus, I restrict my comments about languages other than C++ to generalities and to very specific comments."
That said, I consider C++ the best choice in programming language for a wide variety of people and applications.
When looking at a language comparison consider who wrote it, consider carefully if the descriptions are factual and fair, and also if the comparison criteria are themselves fair for all languages considered. This is not easy.
Well written C tends to be legal C++ also. For example, every example in Kernighan & Ritchie: "The C Programming Language (2nd Edition)" is also a C++ program.
Examples of C/C++ compatibility problems:
int main()
{
double sq2 = sqrt(2); /* Not C++: call undeclared function */
int s = sizeof('a'); /* silent difference: 1 in C++ sizeof(int) in C */
}
Calling an undeclared function is poor style in C and illegal in C++.
So is passing arguments to a function using a declaration that doesn't list
argument types:
void f(); /* argument types not mentioned */
void g()
{
f(2); /* poor style C. Not C++ */
}
In C, a void* can be implicitly converted to any pointer type, and free-store
allocation is typically done using malloc() which has no way of checking
if "enough" memory is requested:
void* malloc(size_t);
void f(int n)
{
int* p = malloc(n*sizeof(char)); /* not C++. In C++, allocate using `new' */
char c;
void* pv = &c;
int* pi = pv; /* implicit conversion of void* to int*. Not in C++ */
}
Note the potential alignment error caused by the implicit conversion
of the void* to a int*.
See
the C++ alternative to void* and malloc().
When converting from C to C++, beware that C++ has more keywords than C:
int class = 2; /* ok in C. Syntax error in C++ */ int virtual = 3; /* ok in C. Syntax error in C++ */Except for a few examples such as the ones shown above (and listed in detail in the C++ standard and in Appendix B of The C++ Programming Language (3rd Edition)), C++ is a superset of C. (Appendix B is available for downloading).
Please note that "C" in the paragraphs above refers to Classic C and C89. C++ is not a descendant of C99; C++ and C99 are siblings. C99 introduces several novel opportunities for C/C++ incompatibilities.
C++ is a direct descendant of C that retains almost all of C as a subset. C++ provides stronger type checking than C and directly supports a wider range of programming styles than C. C++ is "a better C" in the sense that it supports the styles of programming done using C with better type checking and more notational support (without loss of efficiency). In the same sense, ANSI C is a better C than K&R C. In addition, C++ supports data abstraction, object-oriented programming, and generic programming (see The C++ Programming Language (3rd Edition)"; Appendix B discussing compatibility issues is available for downloading).
I have never seen a program that could be expressed better in C than in C++ (and I don't think such a program could exist - every construct in C has an obvious C++ equivalent). However, there still exist a few environments where the support for C++ is so weak that there is an advantage to using C instead.
For a discussion of the design of C++ including a discussion of its relationship with C see The Design and Evolution of C++.
Please note that "C" in the paragraphs above refers to Classic C and C89. C++ is not a descendant of C99; C++ and C99 are siblings. C99 introduces several novel opportunities for C/C++ incompatibilities.
My basic point is that the current C/C++ incompatibilities are "accidents of history" that have no fundamental reasons behind them (though they all "looked like a good idea at the time" to some competent and well-meaning people). The C/C++ incompatibilities provide no benefits to the community at large, cause serious problems to a large section of the C/C++ community, and could - with great difficulty - be eliminated.
For a far more detailed presentation of my views on C/C++ compatibility, see the series of papers I wrote about this:
The current definition of C++ is The ISO C++ Standard described in The C++ Programming Language (3rd Edition).
You can find a more complete timeline and more detailed explanations in The Design and Evolution of C++.
The specific tasks that caused me to start designing and implementing C++ (initially called "C with Classes") had to do with the design of a distributed operating system.
You can find more detailed explanations in The Design and Evolution of C++.
At the time when I developed C++ - and before that when Ken Thompson and Dennis Ritchie developed Unix and C - AT&T was probably the worlds largest civilian user of (and consumer of) software tools. Then, we probably used a wider range of systems - from the tiniest embedded processors to the largest supercomputers and data-processing systems. That put a premium on systems that were applicable in many technical cultures and on many platforms. C and C++ were designed with such demands in mind.
Thus generality is essential, and proprietary features are seen as limiting the choice of platforms and vendors. As a consequence AT&T was and is a major supporter of formal standards (for example, ISO C and ISO C++).
Actually, AT&T made enough money on Cfront, my original C++ compiler, to pay for the development of C++ several times over.
Compiler vendors do not pay royalties to me or to AT&T for C++, and ISO standards are specifications intended for royalty-free use by everyone (once they have paid the ISO or a national standard committee for their copy of the standard). The individual compilers are owned by their respective vendors/suppliers.
"But someone from SCO claimed that they own C++"; is that not so? It's complete rubbish. I saw that interview. The SCO guy clearly had no clue what C++ was, referreing to it as "the C++ languages". At most, SCO may own a 15-year old and seriously outdated version of Cfront - my original C++ compiler. I was careful not to patent or trademark anything to do with C++. That's one reason we write plain "C++" and not "C++(tm)". The C++ standard is unencumbered of patents - the committee carefully checked that also.
Chapter 3 of D&E: ``I picked C++ because it was short, had nice interpretations, and wasn't of the form "adjective C."' In C, ++ can, depending on context, be read as "next," "successor," or "increment," though it is always pronounced "plus plus." The name C++ and its runner up ++C are fertile sources for jokes and puns -- almost all of which were known and appreciated before the name was chosen. The name C++ was suggested by Rick Mascitti. It was first used in December of 1983 when it was edited into the final copies of [Stroustrup,1984] and [Stroustrup,1984c].
The "C" in C++ has a long history. Naturally, it is the name of the language Dennis Ritchie designed. C's immediate ancestor was an interpreted descendant of BCPL called B designed by Ken Thompson. BCPL was designed and implemented by Martin Richards from Cambridge University while visiting MIT in the other Cambridge. BCPL in turn was Basic CPL, where CPL is the name of a rather large (for its time) and elegant programming language developed jointly by the universities of Cambridge and London. Before the London people joined the project "C" stood for Cambridge. Later, "C" officially stood for Combined. Unofficially, "C" stood for Christopher because Christopher Strachey was the main power behind CPL.''
Cfront was a traditional compiler that did complete syntax and semantic checking of the C++ source. For that, it had a complete parser, built symbol tables, and built a complete internal tree representation of each class, function, etc. It also did some source level optimization on its internal tree representation of C++ constructs before outputting C. The version that generated C, did not rely on C for any type checking. It simply used C as an assembler. The resulting code was uncompromisingly fast. For more information, see D&E.
Also, C++ supports programming techniques that allows memory management to be safe and implicit without a garbage collector.
Note that providing a GUI is both a technical and political problem. There are lots of GUIs with lots of users, and generally they wouldn't like some other GUI to be declared standard. Anyway, the standards committee do not have the resources to build a new and better GUI.
Since 1987 or so, the focus of development the C++ language and its associated programming styles have been the use of templates, static polymorphism, generic programming, and multiparadigm programming. This is way beyond the scope of the much-hyped proprietary languages. Another key difference is that C++ supports user-defined types to the same extent as built-in types. This - especially in combination with the use of templates, constructors, and destructors - enables the C++ programmer to use programming and design techniques that (IMO) are more advanced than what is supported in the languages with which C++ is most often compared.
Standard C++ and the design and programming styles it supports owe a debt to the functional languages, especially to ML. Early variants of ML's type deduction mechanisms were (together with much else) part of the inspiration of templates. Some of the more effective functional programming techniques were part of the inspiration of the STL and the use of function objects in C++. On the other hand, the functional community missed the boat with object-oriented programming, and few of the languages and tools from that community benefitted from the maturing experience of large-scale industrial use.
Clearly, I don't think that garbage collection is the sole defining characteristic of "advanced" in the context of programming languages. In particular, note that C++ provides support for effective and efficient memory management techniques that can eliminate resource leaks without the use of a garbage collector. If you disagree, you can just start using a garbage collector for C++; there are good ones available.
void draw_all(vector< Shape*>& vs) // draw each element of a standard vector
{
for_each(vs.begin(),vs.end(),mem_fun(&Shape::draw));
}
Here, Shape* will be an abstract base class defining the interface to
a hierarchy of geometric shapes.
This example easily generalizes to any standard library container:
template< class C> void draw_all(C& cs) // draw each element of a standard container
{
for_each(cs.begin(),cs.end(),mem_fun(&Shape::draw));
}
Jim Coplien's book "Multiparadigm Design for C++" (Addison Wesley, 1998) explores the use of multiple paradigms in the context of design and design methods.
The C++ standard is 740 pages, but that includes 400 pages of library description. The language features are described (in excrusiating detail) in 340 pages. Similarly, TC++PL is 1000+ pages, but only 350 of those are devoted to the explanation of language facilities and their use; the rest discuss libraries, programming techniques, etc.
C++ directly supports (i.e., in the language) what some other languages support through libraries, so the language part will be relatively larger. On the other hand, if yo want to write a "typical modern application", you need to consider operating system interfaces, GUI, databases, web interfaces, etc. the sum of language features, libraries, and programming conventions and standards that you must become familiar with dwarf the programming language. Here, C++'s size can be an advantage as far as it better supports good libraries.
Finally, the days where a novice programmer can know all of a language are gone, at least for the languages in widespread industrial use. Few people know "all of C" or "all of Java" either and none of those are novices. It follows that nobody should have to apologize for the fact that novices do not know all of C++. What you must do - in any language - is to pick a subset, get working writing code, and gradually learn more of the language, its libraries, and its tools.
For a discussion of how embedded systems implementers can address performance issues using Standard C++ (better than by using dialects) see the ISO C++ committee's report on performance. To the best of my knowledge EC++ is dead (2004), and if it isn't it ought to be.
That said, writing C-style programs in C++ is for most applications not an optimal use of C++. To be a really effective C++ programmer, you must use the abstraction mechanisms and the type system in a way that fits reasonably with their intent. Trying to ignore or defeat the C++ type system is a most frustrating experience.
Writing Smalltalk-style in C++ can be equally frustrating and sub-optimal as writing C-style code in C++.
For a more detailed discussion see any of my overview or style papers from my bibliography. In particular, see my OOPSLA paper "Why C++ isn't just an Object-Oriented Programming Language".
"Within C++, there is a much smaller and cleaner language struggling to get out." Yes, that quote can be found on page 207 of The Design and Evolution of C++. And no, that smaller and cleaner language is not Java or C#. The quote occurs in a section entitled "Beyond Files and Syntax". I was pointing out that the C++ semantics is much cleaner than its syntax. I was thinking of programming styles, libraries and programming environments that emphasized the cleaner and more effective practices over archaic uses focussed on the low-level aspects of C.
"I have always wished for my computer to be as easy to use as my telephone; my wish has come true because I can no longer figure out how to use my telephone" I said that after a frustrating attempt to use a "feature-rich" telephone sometime around 1990. I'm sure the sentiment wasn't original, and probably not even the overall phrasing; someone must have thought of that before me.
"There are only two kinds of languages: the ones people complain about and the ones nobody uses". Again, I very much doubt that the sentiment is original. Of course, all "there are only two" quotes have to be taken with a grain o salt.
"Proof by analogy is fraud". Page 692 of TC++PL. A good analogy is an excellent way of illustrating an idea, but far too often such analogies are not accompanied by solid reasoning, data, etc.
Of course not. Read the real IEEE interview.
C++ was initially designed and implemented as a set of general facilities addressing some specific problems that I and my colleagues faced. The generality - and efficiency - of the facilities provided turned out to serve much wider needs than I had anticipated. The emphasis on general facilities - as opposed to the provision of specific solutions to specific problems - has remained with C++ and has served its community well as the specific problems facing the community have changed over the years.
Seriously, I'm looking for fundamental ways of improving the tools and techniques we use to build large real-world systems.