Modified May 26, 2024.
These are questions that people ask me often.If you have better questions or comments on the answers,feel free to email me.Please remember that I can't spend all of my time improving my homepages.
This page concentrates on personal opinions and general questions related tophilosophy.For questions that more directly relate to C++ language features and theuse of C++, seeThe C++ Foundation's FAQ ormyC++ style and technique FAQ.For C++ terminology and concepts, see myC++ glossary.For links to useful sources of C++ information, seemy C++ page andmy C++11 FAQ.For information about my books (incl. reviews and support information), seemy book list.For papers and ISBNs for translations of my books, seemy publication list.
Translations:
For people who can't receive sound, here is a suggestion:Both of my names are pronounced with two syllables: Bjar-neStrou-strup.Neither the B nor the J in my first name are stressed and the NEis 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 thefirst syllable end far down the throat: Strov-strup.The second U is a bit like the OO in OOP, but still short; maybeStrov-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 ofthese 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 thereturn address is invalid or inaccessible.
Two kinds of messages have a relatively high chance of getting lost: homeworkquestions 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 theperson asking doesn't understand that the DOS, Windows, or whatever interfacefrom C++ is not part of the C++ standard (and I cannot keep up with the hugenumber ofC++ libraries).If you fail to receive an answer,please consider if your question was of one of these kinds.
Also, unless you give your name, I am now likely to delete the message unread.This is a new policy.I was never a great fan of pseudonyms,but I find that the chance of a politetechnical conversation with the kind of person who thinks it cool to hide behind a name likesuuupergeeek or coolGuy3 is getting too low for me to bother trying.
What looks "cool and modern" to someone is often considered badtaste by someone else, and fashions change fast.Also,very plain html downloads and displays faster than anything else, and manypeople still suffer from slow web connections.
Classes are there to help you organize your code and to reason about your programs.You could roughly equivalently say that classes are there to help you avoid making mistakesand to help you find bugs after you do make a mistake.In this way, classes significantly helps maintenance.
A class is the representation of an idea, a concept, in the code. An object of a class representsa particular example of the idea in the code. Without classes, a reader of the code would haveto guess about the relationships among data items and functions - classes make such relationshipsexplicit and "understood" by compilers. With classes, more of the high-level structure of yourprogram is reflected in the code, not just in the comments.
A well-designed class presents a clean and simple interface to its users, hiding itsrepresentation and saving its users from having to know about that representation.If the representation shouldn't be hidden - say, because users should be able to changeany data member any way they like - you can think of that class as "just a plain old data structure";for example:
struct Pair { string name, value;};Note that even data structures can benefit from auxiliary functions, such as constructors.When designing a class, it is often useful to consider what's true for every object of theclass and at all times. Such a property is called an invariant. For example, the invariantof a vector could be that its representation consists of a pointer to a number of elementsand that number of elements is stored in an integer. It is the job of every constructor toestablish the class invariant, so that every member function can rely on it.Every member function must leave the invariant valid upon exit.This kind of thinking is particularly useful for classes that manage resource,such as locks, sockets, and files. For example, a file handle class will have the invariantthat it holds a pointer to an open file. The file handle constructor opens the file.Destructors free resources acquired by constructors. For example, the destructor fora file handle closes the file opened by the constructor:
class File_handle {public:File_handle(const char* n, const char* rw){ f = fopen(n,rw); if (f==0) throw Open_failure(n); }~File_handle() { fclose(f); } // destructor// ...private:FILE* f;};If you haven't programmed with classes, you will find parts of this explanation obscure andyou'll underestimate the usefulness of classes.Look for examples. Like all good textbooks,TC++PL has lots of examples.For a less detailed and easier to approach book, seeA Tour of C++.Most modern C++ libraries consist (among other things) of classes and a library tutorialis one of the best places to look for examples of useful classes.There are lots of definitions of "object oriented", "object-oriented programming",and "object-oriented programming languages". For a longish explanation of whatI think of as "object oriented", readWhy C++ isn't just an object-oriented programming language.That said, object-oriented programming is a style of programming originating withSimula (more than 40 years ago!) relying of encapsulation, inheritance, and polymorphism.In the context of C++ (and many other languages with their roots in Simula),it means programming using class hierarchies and virtual functions to allowmanipulation of objects of a variety of types through well-defined interfacesand to allow a program to be extended incrementally through derivation.
SeeWhat's so great about classes?for an idea about what greatabout "plain classes". The point about arranging classes into a class hierarchyis to express hierarchical relationships among classes and use those relationships to simplify code.
To really understand OOP, look for some examples. For example, you might havetwo (or more) device drivers with a common interface:
class Driver {// common driver interfacepublic:virtual int read(char* p, int n) = 0;// read max n characters from device to p// return the number of characters readvirtual bool reset() = 0;// reset devicevirtual Status check() = 0;// read status};This Driver is simply an interface.It is defined with no data members and a set of pure virtual functions.A Driver can be used through this interface and many different kinds of driverscan implement this interface:class Driver1 : public Driver { // a driverpublic:Driver1(Register);// constructorint read(char*, int n);bool reset();Status check();private:// implementation details, incl. representation};class Driver2 : public Driver { // another driverpublic:Driver2(Register);int read(char*, int n);bool reset();Status check();private:// implementation details, incl., representation};Note that these drivers hold data (state) and objects of them can be created.They implement the functions defined in Driver. We can imagine a driver being used like this:void f(Driver& d)// use driver{Status old_status = d.check();// ...d.reset();char buf[512];int x = d.read(buf,512);// ...}The key point here is that f() doesn't need to know which kind of driver it uses;all it needs to know is that it is passed a Driver;that is, an interface to many different kinds of drivers.We could invoke f() like this:void g(){Driver1 d1(Register(0xf00));// create a Driver1 for device// with device register at address 0xf00Driver2 d2(Register(0xa00));// create a Driver2 for device// with device register at address 0xa00// ...int dev;cin >> dev;if (dev==1) f(d1);// use d1elsef(d2);// use d2// ...}Note that when f() uses a Driver the right kind of operations are implicitly chosen at run time.For example, when f() is passed d1, d.read() uses Driver1::read(), whereas when f() is passed d2,d.read() uses Driver2::read(). This is sometimes called run-time dispatch or dynamic dispatch.In this case there is no way that f() could know the kind of device it is called with becausewe choose it based on an input.Please note that object-oriented programming is not a panacea. "OOP" does not simply mean "good"- if there are no inherent hierarchical relationships among the fundamental concepts in your problemthen no amount of hierarchy and virtual functions will improve your code. The strength of OOPis that there are many problems that can be usefully expressed using class hierarchies - the mainweakness of OOP is that too many people try to force too many problems into a hierarchical mould.Not every program should be object-oriented. As alternatives, considerplain classes,generic programming,and free-standing functions (as in math, C, and Fortran).
Generic programming is programming based on parameterization:You can parameterize a type with another(such as a vector with its element types) and an algorithm with another(such as a sort function witha comparison function). The aim of generic programming is to generalize a useful algorithm or datastructure to its most general and useful form. For example, a vector of integers is fine and so isa function that finds the largest value in a vector of integers. However, a generic solution thatprovides a vector of any type the user cares to use and a function that finds the largest value inany vector is better still:
vector<string>::iterator p = find(vs.begin(), vs.end(), "Grail");vector<int>::iterator q = find(vi.begin(), vi.end(), 42);These examples are from the STL (the containers and algorithms part of the ISO C++ standard library);for a brief introduction, seeA Tour of C++ fromTC++PL.
In C++20 we can simplify that example to
auto p = find(vs, "Grail");auto q = find(vi, 42);
Generic programming is in some ways more flexible than object-oriented programming.In particular, it does not depend on hierarchies.For example, there is no hierarchicalrelationship between an int and a string.Generic programming is generally more structured than OOP;in fact, a common term used to describe generic programming is "parametric polymorphism",with "ad hoc polymorphism"being the corresponding term for object-oriented programming.In the context of C++, generic programmingresolves all names at compile time; it does not involve dynamic (run-time) dispatch.This has led generic programming to become dominant in areas where run-time performance is important.
Please note that generic programming is not a panacea.There are many parts of a program that need no parameterization and many exampleswhere run-time dispatch (OOP) is needed.
For an ambitious project to make C++ easier to use and safer without damaging its efficiency or flexibility, seethe Core C++ Guidelines.
For people who haven't programmed before or come from another language and want arelatively gentle introduction to modern C++, considerProgramming: Principles and Practice using C++.This is the book I wrote for a freshman (1st year university students) programming classand it has benefitted from three years of classroom use.
For people who are programmers and willing to learn new conceptsand techniques from a classical textbook, I recommend The C++ Programming Language (4th 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 languageor casual programmers trying to gain a superficial understanding of C++ as fastas possible.Consequently, this book focuses on concepts and techniques and goes to some pain tobe complete and precise.It describes "pure C++," that is, the language independently ofany particular software development environment or foundationlibrary (except the standard library, of course).It contain comprehensive coverage of the standard library.
If you are already an experienced programmer and want a quick overview of what C++ has to offer, considerA Tour of C++ (second efition).It presents the major features of C++ and its standard library in 200 pages.
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 constraintshelps writing better programs.Thriving in a Crowded and Changing World: C++ 2006-2020can be seen as an up-to-date follow-up to D&E.
AtTAMU,we useProgramming: Principles and Practice using C++to get freshmen (1st year students) through the fundamentals of C++ and theprogramming techniques it support (notablyobject-oriented programming andgeneric programming)in a semester.
On the other hand, if you want to be fully comfortable with all themajor C++ language constructs, with data abstraction, Object-Orientedprogramming, generic programming, Object-Oriented design, etc., you caneasily spend a year or two - if you aren't already acquainted withthose techniques (say, from Java or C#).
Is that then the time it takes to learn C++?Maybe, but then again, that is the timescale we have to consider tobecome better designers and programmers. If a dramatic change of thewaywe work and think about building systems isn't our aim, thenwhy bother to learn a new language?Compared to the time required to learn to play the piano well or tobecome fluent in a foreign (natural) language, learning a new anddifferent programming language and programming style is easy.
For more observations about learning C++ see D&E ora note from comp.lang.c++that I wrote some time ago.
SeeLearning Standard C++ as a New Languagefor a discussion of the choice of C++ constructs, techniques, and librariesfor early learning.For an example of books that takes that approach systematically, seeStroustrup:Programming: Principles and Practice using C++ andKoenig&Moo: "Accelerated C++" from Addison Wesley'sC++ In Depth series.
You'll need a textbook for learning C++.This is the case even when your implementation comes with ample on-linedocumentation.The reason is that language and library documentation together with sample code are not goodteachers of concepts.Typically such sources are silent about why things are the way they are andwhat 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 thestandard library facilities in an integrated manner from the start.For example, reading a string from input should look something like
string s;// Standard C++ stylecin >> s;and not like this
char s[MAX];/* Standard C style */scanf("%s",s);Look for book recommendations from programmers with solid C++ experience.I recommendProgramming: Principles and Practice using C++,but remember thatno one book is the best for everyone.Have a look at thebook reviewson the ACCU (The Association of C and C++ Users) site.
Aim to write idiomatic C++: avoid simply writing code in the style of yourprevious language using C++ syntax; there is little to be gained fromsimply changing syntax.
Also, no, I will not suggest "a good project for a student to work on".My experience is that learning enough about a student andhis/her course to know what level of difficulty is required and what kind ofproject is of interest 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 takeseveral messages and several hours. I just don't have that kind of time.Remember, these request come at least weekly. Finally, some students seemto have the idea that if I suggest a project, I am morally obliged toprovide quite detailed help in its completion.
Ideas: Look at the exercises inTC++PLor other good textbooks. Many of those exercises are designed to keep a studentbusy for several days, and reading those exercises can inspire an enterprisingstudent to so something similar.Or look at the non-computer-science part of your world: Maybe a biology projectcould use support for a new measurement device or a friend studying historycould use an improved database interface. Many of the best projects and thebest uses of computers are outside traditional computer science.
See alsomy C++ style and techniques FAQ.Real novices facing their first "read some data, do something to it, andproduce some output" exercise might be interested ina very simple programora program reading a string from input.
The current standard,C++14,was approved in 2014 and good implementationt arealready shipping.C++11/C++14 is described in thecurrent editions of my books.
The C++ standard (ISO/IEC 14882) is available for downloading at thethe ANSI Electronic Store.Search for "14882", to find "INCITS/ISO/IEC 14882-2003 Programming Languages - C++"The cost is (as I write this) US$30.00 payable on-line via credit card.The downloaded document is in PDF form, about 3Mb total size.
Look atISOcpp/standardizationfor informations about the standard, standaridzation effort, and a late working paper (available for free).The current standard is C++17, but C++20 has been approved and will become official late 2020.
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(e.g., the declarator syntax and array decay) are partof the C subset of C++ and couldn't be removed without doing harm toprogrammers working under real-world conditions.C++'s C compatibility was a key language design decision rather than amarketing 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 allow a programmer to refrain from usingthe most troublesome C features. For example, standard librarycontainerssuch as vector, list, map, and string can be used to avoid most trickylow-level pointer manipulation.
It is now shipping from amazon, fromthe publisher, and elsewhere.
There are no current plans for a 5th edition.
A summary:
Addison-Wesley offers electronic versions throughSafari online books service and elsewhere.
For an incomplete list of C++ implementations, seemy C++ compilers list.
Also, where possible, prefer the standard library to non-standard "foundationlibraries" and try to minimize use of proprietary extensions.
The problem seems to be an interesting little exercise that John Bentley once proposed to me: Insert a sequence of random integers into a sorted sequence, then remove those elements one by one as determined by a random sequece of positions: Do you use a vector (a contiguously allocated sequence of elements) or a linked list?For example, seeSoftware Development for Infrastructure.I use this example to illustrate some points, encourage thought about algorithms, data structures, and machine architecture, concluding:
I used that example in several talks, notably:
This video has been popular: It has been downloaded more than 250K times (plus another 50K+ times at verious other sites). My impression is that many viewers failed to understand that the purpose of that example is to illustrate some general principles and to make people think.Initially, most people say ``List of course!'' (I have tried asking that question many times) because of the many insertions and deletions ``in the middle'' (lists are good at that).That answer is completely and dramatically wrong, so it is good to know why.I have been using the example for years, and had graduate students implement and measure dozens of variants of this exercise and different exercises.Examples and measurements by others can be found on the Web.Of course,
And, yes, my recomendation is to usestd::vector by default.More generally, use a contiguous representation unless there is a good reason not to.Like C, C++ is designed to do that by default.
Also, please don't make statements about performance without measurements.I have seen a case where changing a zero-to-two-element list to a zero-to-two-element vector made a factor-of-two difference to an algorithm. I didn't expect that. Nor did other experts looking at the code.
Much of the relative simplicity of Java is - like for most newlanguages -partly an illusion and partly a function of its incompleteness.As time passes, Java will growsignificantly in size and complexity. It will double or triple in sizeand grow implementation-dependent extensions or libraries.That is the way every commerciallysuccessful language has developed. Just look at any language youconsider successful on a large scale. I know of no exceptions,and there are good reasons for this phenomenon.[I wrote this before 2000; now (2012),the language part of the Java 7 specification is slightly longer in terms of number of pages than the ISO C++11 language specification.]
I have commented (negatively) about Java hype and ascribed much of Java's success to marketing.For example, seemy HOPL-3 paper.Today (2010), the claims made about Java are more reality based and less gratuitously derogative about alternatives.This was not always so. For example, compare theoriginal 1995 Java white paperwith the versions you find on the web (sometimes labelled "the original Java whitepaper"); page 69 would be a good place to start.
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 ineachcase you are writing code for a platform owned by a single corporationand tweaked for the commercial benefit of that corporation.It has been pointed out that you can write programs in any language forthe JVM and associated operating systems facilities. However, the JVM,etc.,are heavily biased in favor of Java. It is nowhere near being a generalreasonably language-neutral VM/OS.
Personally, I'll stick to reasonably portable C++ for most of the kindof 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 - alternativeon that platform.
The CLI provides a set of interfaces (to system facilities) that are very different from traditionalinterfaces to operating system facilities and applications.In particular, these interfaces have semantics thatcannot be completely or conveniently expressed in conventional programming languages.One way of describing CLI is as a (partial) "platform" or "virtual machine". It consists of alarge set of language features (inheritance, methods, loop constructs, callback mechanisms, etc.),supporting a large set of foundation libraries (the BCL), plus an elaborate system of metadata.The CLI is sometimesdescribed as "language neutral". However, a language that doesn't accept a large subset ofthese facilities cannot use even basic .Net facilities(or future Microsoft Windows facilities, assuming that Microsoft's plans don't change)and a language that cannot expressall of thesefeatures cannot be used for the implementation of resources meant to be usable by other languages.Thus, CLI is "language neutral" only in the sense that every language must support all of the CLIfeatures to be "first-class" on .Net.
I prefer a binding to be a few primitives, expressible as simple function calls and simpledata structures in any language, possibly encapsulated in language-specific libraries.For the CLI, this can at best be done for consumers of CLI facilities only. A languageused to produce CLI modules must be able to express all of the CLI facilities, includingthe metadata.Only a language that can do that can be considered a systems programming language on .Net. Thus, the Microsoft C++ team concluded that only build-in language facilitiesare acceptable to their customers.Their design reflects a view that accepts absolutely no restrictions on what part of CLI can beexpressed in C++ with the C++/CLI extensions,absolutely no verbosity compared to other languages when using CLI facilities,and absolutely no overheads compared to other languages.They aim at preserving C++ as the dominant systems programming language for Windows.
As ever,I place a heavy emphasis on portability andrecommend people to design applications so that access to system-specific facilities are throughwell-defined interfaces specified in ISO C++ (e.g., not to use C++/CLI directly).On Windows, this will sometimes be inconvenient compared with using C++/CLIfacilities directly, but it's the only way to gain portability and a degree of vendor independence.Obviously, that arms-length approach to the CLI cannot be maintained if the purpose of a piece ofcode is to provide a CLI interface to be consumed by other code.Please note that I recognize the need for system-specific extensions and that Microsoft is notthe only C++ vendor with such extensions, I just strongly prefer to deal with such extensionsthrough a "thin interface" specified in ISO standard C++.
How to deal with system-specific extensions is inherently a difficult question.The Microsoft C++ team, especially Herb Sutter, has kept up an active dialog with (other) membersof the ISO C++ standards committee so that the relationship between ISO C++ and its superset C++/CLIwill eventually be worked out.We have a long record of constructive joint work in the ISO C++ committee.Also, to minimize confusion between ISO C++ and the C++/CLI extensions, Microsoft is now revisingtheir Visual C++ documentation to try to clearly distinguish C++/CLI from ISO C++(plain unqualified C++ means ISO C++).I hope others will follow that lead.
On the difficult and controversial question of what the CLI binding/extensions to C++ is to be called,I prefer C++/CLI as a shorthand for "The CLI extensions to ISO C++".Keeping C++ as part of the name reminds people what is the base language and willhelp keep C++ a proper subset of C++ with the C++/CLI extensions.TheC/C++ compatibility problemsdemonstrate how important it is to keep that subset property.
Here are some documents related to C++/CLI:
Often a successful application/program have customers/users who prefer a variety of platforms.The set of desirable platforms change as the user population changes. Being tied to a singleplatform or single vendor, limits the application/program's potential use.
Obviously, complete platform independence is incompatible with the ability to use all platformspecific facilities. However, you can often approximate platform independence for an applicationby accessing platform facilities through a "thin interface" representing the application's viewof its environment as a library.
"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 requiresmore 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 impartialitywould never be fully credible.
I also worry about a phenomenon I have repeatedly observed inhonest attempts at language comparisons.The authors try hard to be impartial, but are hopelessly biased byfocusing on a single application, a single style of programming, ora 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 languageare deemed minor and simple workarounds are presented, whereas similarflaws in other languages are deemed fundamental.Often, the workarounds commonly used in theless-well-known languages are simply unknown to the people doing thecomparisonor deemed unsatisfactory because they would be unworkable in the morefamiliarlanguage.
Similarly, information about the well-known language tends to becompletelyup-to-date, whereas for the less-known language, the authors rely onseveral-year-old information.For languages that are worth comparing, a comparison of language X asdefinedthree years ago vs. language Y as it appears in the latest experimentalimplementation is neither fair nor informative.Thus, I restrict my comments about languages other than C++ togeneralitiesand to very specific comments."
That said, I consider C++ the best choice in programming language for awidevariety 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 alllanguages considered.This is not easy.
Well written C tends to be legal C++ also. For example, every examplein Kernighan & Ritchie: "The C Programming Language (2nd Edition)" isalso 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 listargument 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-storeallocation is typically done using malloc() which has no way of checkingif "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 conversionof the void* to a int*.Seethe 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 ofThe 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 severalnovel 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 widerrange of programming styles than C.C++ is "a better C" in the sense that it supports the styles of programmingdone using C with better type checking and more notational support (withoutloss 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(seemy books).
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 anobvious 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.There aren't all that many of those left, though; seemy (incomplete) compilers list.
For a discussion of the design of C++ including a discussion of itsrelationship with C seeThe 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 severalnovel opportunities for C/C++ incompatibilities.Here is a description of thedifferences between C++98 and C99.
My basic point is that the current C/C++ incompatibilities are "accidents ofhistory" that have no fundamental reasons behind them (though they all"looked like a good idea at the time" to some competent and well-meaningpeople).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, seethe series of papers I wrote about this:
Please note that these papers were written in late 2001 and early 2002 when it was still possibleto imagine coordinated action by the C and C++ standards committees leading to practical results bythe end of the decade. This didn't happen.
At the time, I considered C the best systems programming language available.That was not as obvious then (1979) as it later became,but I had experts such asDennis Ritchie,Steve Johnson,Sandy Fraser,Greg Chesson,Doug McIlroy, andBrian Kernighandown the corridor from whom I could learn and get feedback.Without their help and advice, and without C, C++ would have been stillborn.
Contrary to repeated rumors,I was never told that I had to use C; nor was I ever told not to use C.In fact, the first C++ manual grew from troff source of the C manual that Dennis gave me.Many new languages were designed at Bell labs; in "Research" at least, there were norules enforcing language bigotry.
There is no language called "C/C++".The phrase is usually used by people who don'thave a clue about programming (e.g. HR personnel and poor managers).Alternatively, it's used by people who simple do not know C++ (and often not C either).When used by programmers,it typically indicates a "C++ is C with a few useful and a lot of useless complicated features added"attitude.Often, that is the point of view of people who like to write their own strings and hash tables withlittle knowledge of the standard library beyond printf and memcpy. There are people who stick to a restricted subset of C++ for perfectly good reasons,but they (as far as I have noticed) are not the people who say "C/C++".
I use C/C++ only in phrases such as "C/C++ compatibility" and "C/C++ community".
The current definition of C++ The 2011 ISO C++ Standard described inThe C++ Programming Language (4th Edition).
You can find a more complete timeline and more detailed explanations inThe Design and Evolution of C++ andA History of C++: 1979-1991 andEvolving a language in and for the real world: C++ 1991-2006.
The specific tasks that caused me to start designing and implementing C++(initially called "C with Classes") had to do with distributingoperating system facilities across a network.
You can find more detailed explanations inThe Design and Evolution of C++.See alsoA History of C++: 1979-1991 andEvolving a language in and for the real world: C++ 1991-2006.
At the time when I developed C++ - and before that when Ken Thompson andDennis Ritchie developed Unix and C - AT&T was probably the worlds largestcivilian user of (and consumer of) software tools. Then, we probably useda widerrange of systems - from the tiniest embedded processors to the largestsupercomputers and data-processing systems. That put a premium on systemsthat 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 limitingthe choice of platforms and vendors. As a consequence AT&T was and is a majorsupporter 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 ISOstandards are specifications intended for royalty-free use by everyone(once they have paid the ISO or a national standard committee for theircopy 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, referring to it as"the C++ languages".At most, SCO may own a 15-year old and seriously outdated version of Cfront - my originalC++ compiler. I was careful not to patent or trademark anything to do with C++. That's onereason we write plain "C++" and not "C++(tm)".The C++ standard is unencumbered of patents - the committee carefully checked that also.
Chapter 1 ofTC++PL:``The name C++ (pronounced "see plus plus") was coined by Rick Mascitti in the summer of 1983.The name signifies the evolutionary nature of the changes from C; "++" is the C incrementoperator. The slightly shorter name "C+" is a syntax error; it has also been used as the name of anunrelated language. Connoisseurs of C semantics find C++ inferior to ++C. The language is notcalled D, because it is an extension of C, and it does not attempt to remedy problems by removingfeatures. For yet another interpretation of the name C++, see the appendix of [Orwell,1949].''
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 descendantof BCPL called B designed by Ken Thompson.BCPL was designed and implemented by Martin Richards from Cambridge Universitywhile 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 ofCambridge 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 semanticchecking of the C++ source.For that, it had a complete parser, built symbol tables, and built a completeinternal tree representation of each class, function, etc.It also did some source level optimization on its internal tree representationof 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, seeD&E.
Let's first be perfectly clear: No, I did not anticipate the run-away success of C++ and no, I did not foresee every technique used with C++ or every application of C++. Of course not!
However, statements like these are very misleading:
This FAQ was prompted by seeing these and several more of their ilk today.
I did outline the criteria for the design and implementation of C++.I did explicitly aim for generality: "I'm not interested in a language that can only do what I can imagine" and for efficiency "a facility must not just be useful, it must be affordable."I suggest that doubters readThe Design and Evolution of C++ and myHOPL2 andHOPL3 papers (these are peer-reviewed papers).As for deterministic destruction, it was in "C with Classes" in the first week or two (1979).I held back the introduction of exceptions into C++ for half a year until I discovered RAII (1988).RAII is an integral and necessary part of the C++ exception mechanism.
I was very surprised when Jeremy Siek first showed me the compile-timeif that later becamestd::conditional, but I had aimed for generalty (and gotten Turing completeness modulo translation limits).I opposed restrictions to C++ immediately when Erwin Unruh presented what is widely believed to be the first template metaprogram to the ISO Standards committee's evolution working group. To kill template-metaprogramming, all I would have had to do was to say nothing. Instead my comment was along the lines "Wow, that's neat! We mustn't compromise it. It might prove useful."Like all powerful ideas, template-metaprogramming can be misused and overused, but that does not imply that the fundamental idea of compile-time computation is bad.And like all powerfuls ideas, the implications and techniques emerged over time with contributions from many individuals.
There is more to scolarship than a look at the wikipedia, a quick Google-search, and a couple of blog posts.There is more to invention than giving a simple list of implications. Fundamental principles and design guidelines are essential.My part of the C++ design opened the possibility formany to contribute, and if you look at my writings and postings, you see that I try hard to give credit (e.g., see the reference sections ofmy C++11 FAQ) or the history sections ofmy books.
And no, I'm not a walking C++ dictionary.I do not keep every technical detail in my head at all times.If I did that, I would be a much poorer programmer.I do keep the main points straight in my head most of the time, and I do know where to find the details when I need them.For example:
Also, C++ supports programming techniques that allows memory management tobesafe and implicit without a garbage collector.I consider garbage collection a last choice and an imperfect way of handling for resource management.That does not mean that it is never useful, just hat there are better approaches in many situations.
C++11 offers a GC ABI.
I don't like garbage.I don't like littering.My ideal is to eliminate the need for a garbage colletor by not producing any garbage.That is now possible.Tools supporting and enforcing the programming techniques that achieves that are being produced.For an overview, seeA brief introduction to C++'s model for type- and resource-safety..
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 otherGUI to be declared standard.Anyway, the standards committee do not have the resources to build a new and better GUI.
One simple thing that confuses many discussions of language use/popularity is the distinction between relative and absolute measures. For example, I say (in 2011) that C++ use is growing when I see user population grow by 200,000 programmers from 3.1M to 3.3M. However, somebody else may claim that "C++ is dying" because it's "popularity" has dropped from 16 percent to 11 percent of the total number of programmers. Both claims could be simultaneously true as the number of programmers continues to grow and especially as what is considered to be programming continues to change. I think that C++ is more than holding its own in its traditional core domains, such as infrastructure, systems programming, embedded systems, and applications with serious time and/or space and/orpower consumption constraints.See alsomy DevX interview.
Thefirst ISO C++ standard was ratified in 1998.The next versionC++11,is complete and shipping.You can find papers describing C++11 onmy publications pageand all documents relating to the new standard onthe ISO C++ committee's home pages.MyHOPL-iii paper on the last 15 years of C++ evolutionmay the best explanation of what is being done and why.Arecent interviewcontains lists of new language features and standard libraries.
When considering the evolution of C++, it is worth remembering that the aim is not to add the largestnumber of new features, but to improve C++ for its key application domains, including systemsprogramming and library building, without breaking older code(there are billions of lines of C++ "out there").
Since 1987 or so, the focus of development the C++ language and its associatedprogramming styles have been the useof templates, static polymorphism, generic programming, and multiparadigmprogramming. This is way beyond the scope of the much-hyped proprietarylanguages. Another key difference is that C++ supports user-defined typesto the same extent as built-in types. This - especially incombination with the use of templates, constructors, and destructors -enables the C++ programmer to useprogramming and design techniques that (IMO) are more advanced than what issupported in the languages with which C++ is most often compared; e.g. seeRAII.
Standard C++ and the design and programming styles it supports owe a debtto the functional languages, especially to ML.Early variants of ML's type deduction mechanisms were (together with muchelse) part of the inspirationof templates. Some of the more effective functional programmingtechniques were part of the inspiration of the STL and the use of functionobjects in C++.On the other hand, the functional community missed the boat withobject-oriented programming, and few of the languages and tools from thatcommunity benefited from the maturing experience of large-scale industrialuse.
Clearly, I don't think thatgarbage collection is the sole definingcharacteristic of "advanced" in the context of programming languages.In particular, note that C++ provides support for effective and efficientmemory management techniques that can eliminate resource leaks without theuse 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(),[](Shape* p){ p->draw(); });}Here, Shape will be an abstract base class defining the interface toa 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(),[](Shape* p){ p->draw(); });}Jim Coplien's book "Multiparadigm Design for C++" (Addison Wesley, 1998)explores the use of multiple paradigms in the context of designand design methods.
We need a better -- more descriptive -- term to replace ``multi-paradigm.''
The C++ standard is 1151 pages; that includes 430 pages of language definition and 770 pages of standard-library description.The size of the language definition is within 5% of the language descriptions of Java and C# (measured by page count).Similarly,TC++PL is 1360 pages; of those 750 of those are devoted to language facilities and programming techniques; the rest discuss libraries, 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 you want to writea "typical modern application", you need to consider operating system interfaces, GUI,databases, web interfaces, etc. the sum of language features, libraries, and programmingconventions 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 thelanguages in widespread industrial use. Few people know "all of C" or "all of Java" either and noneof those are novices. It follows that nobody should have to apologize for the fact thatnovices 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 my suggestion on how beginners can approach C++, seeProgramming: Principles and Practice using C++.
For a discussion of how embedded systems implementers canaddress performance issues using Standard C++ (better than by using dialects)see the ISO C++ committee'sreport on performance.To the best of my knowledge EC++ is dead (2004), and if it isn't it ought to be.
For a look at how ISO C++ can be used for serious embedded systems programming, seethe JSF air vehicle C++ coding standards.
That said, writing C-style programs in C++ is for most applications notanoptimal use of C++. To be a really effective C++ programmer, you mustusethe abstraction mechanisms and the type system in a way that fitsreasonablywith their intent. Trying to ignore or defeat the C++ type system is amost frustrating experience.
Writing Java-style code in C++ can be as frustrating andsub-optimal aswriting C-style code in C++.
For a more detailed discussion see any of my overview or style papersfrom mybibliography.In particular, see my OOPSLA paper "Why C++ isn't just an Object-Oriented Programming Language".
Of course not. Readthe real IEEE interview.
C++ was initially designed and implemented as a set of generalfacilities addressing some specific problems that I and my colleagues faced.The generality - and efficiency - of the facilities provided turned out toserve much wider needs than I had anticipated.The emphasis on general facilities - as opposed to the provision of specificsolutions to specific problems - has remained with C++ and has served itscommunity well as the specific problems facing the community have changedover the years.
PS. I work for Morgan Stanley, not J.P. Morgan.Morgan Stanley is a fairlyheavily-regulatedbank, rather than a generic ``financial institution,''and IMO one of the most ethically-run financial institutions.
PPS. You simply cannot run a modern society without banks.
PS. Texas A&M University != University of Texas.
Seriously, I'm looking forfundamental ways of improving the tools and techniques we use to buildlarge real-world systems.One part of my work isC++11.
Look at my papers forHOPL-2 andHOPL-3;HOPL stands for "History Of Programming Languages", the premier conference on that subject, sponsored by the ACM. These are heavily peer-reviewed papers.For even more information see my bookThe Design and Evolution of C++ and thePreface to the 2006 Japanese translation of D&Ewhich brings the information up to 2006.Also, many of myinterviewstouch upon the issues of background, design, and history of C++.
The Boost libraries have tests suites, have documentation, have been tested on multiple systems,and are peer reviewed.
I have two problems with Boost, though, which I hope will be dealt with eventually:
Like all powerful techniques they are easily overused.Personally, I tend to use templates primarily for generic programming (e.g., defining containers and algorithms over containers) and for templates that generate fairly obvious code based on template arguments (e.g., generating buffers and register access code); that's sometimes called generative programming.Be careful about the complexity of the templates you write or use; it is easy to get overenthusiastic and write template code that is too clever to be useful as maintainable production code.
If you do not like functional programming styles, you might find template metaprograms hard to understand. If you do like functional programming, you may find the template version a bit primitive, but remember these templates are executed at compile-time.
C++'s support for metaprogramming is improving.Conceptswill dramatically simplify generic programming and make much of the scaffolding for template metaprogramming redundant.Furthermore if what you want to generate is a value (say and integer value),constexpr functionsare far easier to use (and compile faster).