The popularity of C++ has varied throughout the years since its introduction in the 1980s.  The rise of managed languages like Java and C# along with the emergence of scripting languages like JavaScript, Python, and Ruby has affected C++'s adoption.  Yet many supporters like C++ for the control, raw power, and speed that it offers.  C++11 promises to bring that power to programmers in a more efficient manner, and the changes it introduces illustrate how much the language has grown in the past 30 years.  Programmers looking to learn about C++11 or perhaps sample C++ for the first time would do well to try C++ Primer, 5th Edition by Stanley B. Lippman, Josée Lajoie, and Barbara E. Moo.  InfoQ had the opportunity to speak with Ms. Moo about her new book and the C++ language as a whole. 

InfoQ: Lets start with the approach of your new book.  You previously coauthored "Accelerated C++" which takes the approach of teaching C++ around its standard library.  C++ Primer 5th Edition continues this style.  By comparison, the author of 3rd Edition used a completely different method (C plus C++).  I bring this up because I think it would be beneficial to discuss this philosophical shift in how the language as a whole is taught as well as the changes required to introduce C++11.  How did you and the new team become part of this project? 

Related Sponsored Content The DevOps Engineer's Guide to Kubernetes Configurations Best Practices Barbara: Thanks.  Indeed it was the success of Accelerated C++ that led AW to ask me to work on the 4th Edition of the Primer.  The C++ Primer really has an important role in the C++ community.  Since 1989, when the Primer was initially published, it has been more or less the gateway book for serious programmers that want a tutorial introduction to C++. 



The first three editions of the C++ Primer were motivated by changes in the language.  The 3rd Edition, which was published in 1998, focused on the 1998 standardization of C++.  That edition was published before the new standard library was widely available.  It was also published before Accelerated C++ demonstrated the advantages of teaching the library along with the language rather than as an advanced topic.  Unlike previous editions of the C++ Primer, the primary motivation for the 4th Edition was to revise its teaching strategy.  We decided to use the same teaching approach as Accelerated C++ and in particular to incorporate the library right from the start of the book.  Unfortunately, too many C++ books still teach low-level facilities based on arrays and pointers and teach the library as an advanced topic.  But, using arrays and pointers is much more error-prone and harder to understand.  Even worse, to simplify using arrays, many books end up teaching bad habits, such as using fixed-size arrays.  It is so much easier to write programs using the string and vector types.  So, we present these types early in the Primer.  When the new C++ 11 standard was nearing completion we decided to use the same strategy for presenting the new features.  We completely revised the book to present the language as an integrated whole rather than teaching the new features as advanced topics grafted onto the existing language.  Some of the new C++ 11 features in particular auto and decltype, range-based for statement, and smart pointers make writing programs much easier, so we teach these facilities along with other basics of the language. 

InfoQ: What features of the new C++11 standard do you like the most? 

Barbara: Well, I guess I sort of started to answer this question in the last one!  The new auto and decltype type specifiers let programmers obtain the benefits of static typing (catching errors at compile time) without burdening programmers with writing long complicated type declarations or having to search through the program to know which type is needed.  Smart pointers make it easier and safer to use dynamic memory, but I think the biggest boon from smart pointers is that using them makes it easier to write classes that manage resources.  Classes that use smart pointers (in place of ordinary pointers) don’t need to define the assignment operator, copy constructor, and destructor.  That means we can write fairly complex classes without having to teach about copy control. 

Some other features that I like are the new library facilities for programming with functions e.g., bind and function.  These new facilities are much cleaner and uniform to use.  Also, lambdas, which can be thought of as lightweight functions, make it easier to use and customize the behavior of the standard algorithms. 

One really important change is one that many programmers may ignore but will benefit from anyway, which is rvalue references and move semantics.  The ability to move rather than copy an object is something that is needed only for some kinds of classes.  In practice I suspect that only fairly sophisticated programmers will directly write move operations.  However, avoiding copies when an object can be moved does provide a BIG boost to the performance of the standard library containers and string class. 

InfoQ: Anything crucial that was overlooked? 

Barbara: No, not really.  The committee had a draft for concepts, which was an attempt to add constraints checking to the language that got omitted.  I think that was a good choice because the design really wasn’t ready. 

InfoQ: How do you see C++ fitting in with today's software development world given today's popular areas (mobile/web/cloud)?  There have been a numerous languages with various levels of popularity (Python / C# & Java / Go /etc) How do you feel C++ compares when starting a new project? ( Or is it a matter of using C++11 for legacy C++ code bases?) 

Barbara: Well, these languages differ from each other and from C++ in a number of important ways including both technical and nontechnical issues.  With the exception of Go, with which I am not really familiar, these languages differ from C++ significantly and target different kinds of applications.  If I’m writing a large-scale application that has rigorous performance, portability, hardware interface, or scale requirements these languages aren’t appropriate.  On the other hand, if I’m building an application that is dominated by interaction with the user, then I’m probably looking at one of these kinds of languages. 



As to the specific question of mobile/web/cloud computing, C++ is used for these kinds of applications as well.  C++ is used to manage the server (in the cloud) computing.  And of course, it’s also used for the operating systems that control the mobile devices themselves.  So, even in this newest part of the computing industry there’s widespread use of C++.  There’s another important difference between C++, Python, and to a lesser extent Java, and languages like C#, Go, and Objective-C. The first group of languages have an open (or in the case of Java at least partially open) evolution process.  As a result they are available on a wide variety of platforms.  The same is not true for the second group.  These languages are captive to particular corporate sponsors.  Microsoft wants C# to be cross-platform but realistically it’s used only for projects that run on MS operating systems.  So far Go is a Google language and Objective-C has little use outside Apple’s iOS applications.  If you’re writing an application that can be tied to a single platform, then these languages are suitable.  If not, then you really need to think about what happens when you need to support other hardware or operating systems. 

InfoQ: C++ has been described as 3 separate languages: the C pre-processor which has no knowledge of scope, the C++ runtime language, and the C++ compile time language-templates.  Do you consider the C++ language that segmented?  And if so, how much of an issue is it? 

Barbara: No, I think that’s an overstatement.  Yes, there is a preprocessor and yes it is disconnected from the C++ language itself.  But, aside from #include and conditional compilation there’s been little reason to use the preprocessor in C++ since the mid-80s once C++ had inlines and const.  As a result, most C++ programmers don’t even think about the preprocessor and needn’t be familiar with its additional facilities. 

As to the distinction between the “run time” and “compile time” language, I think that’s a distinction that matters more to language designers and implementers than to programmers.  Aside from those few C++ programmers who do template metaprogramming, many, probably most, C++ programmers, never think about the distinction between runtime and compile time when they use templates versus the other parts of the language.  At most the distinction they see regarding templates is that they may not hear about errors until later in the compilation cycle.  That may be a surprise at first, but it’s not a huge issue.  A far bigger issue for programs that use templates is the state of the art regarding compiler error messages! 

InfoQ: Some arguments against using C++ are its lengthy compile times and/or cryptic compilation errors.  Do you see that as a real obstacle to be overcome or is it somewhat exaggerated? ( In this case, there are some challenges but the power is worth the price?) 

Barbara: As to compilation times, I think this used to be a much bigger deal than it is today.  Like many other software systems, compilation times have gotten faster as machines have gotten faster.  If you think about it, since the mid 1980s, when we started working on C++, machines have gotten about 1000 times faster.  Systems haven’t gotten a thousand times bigger, so compilation times today are relatively much, much faster than they were when C++ got its reputation for slow compile times.  Of course, teams that work on very large systems still have to give attention to how they organize their code in order to reduce compilation times.  Unfortunately I think that’s a fact of life for large projects regardless.  As to cryptic error messages I think that’s a problem primarily regarding code that involves templates.  I do wish compiler writers would put more effort into reporting template-related errors in terms used in the code itself rather than reporting errors using internal generated names.  I primarily used the gcc compiler to test the code in the Primer and I must admit that the error messages relating to template-based code were useful to find the right line of code but too often didn’t help to much in figuring out what was wrong. 

InfoQ: Since our last conversation Microsoft and others announced the Standard C++ Foundation.  How do you feel this will affect C++ usage?  What is your opinion on their goals to provide a central C++ location and a quicker release cycle of new standards? 

Barbara: As to the Standard C++ Foundation I am not real familiar with it yet and, of course, they’ve just started.  I applaud the effort and so far it looks like it will be an interesting site to track. 

About the Interviewee

Barbara E. Moo is an independent consultant with 20 years' experience in the software field.  During her nearly 15 years at AT&T, she worked on one of the first commercial products ever written in C++, managed the company's first C++ compiler project, and directed the development of AT&T's award-winning WorldNet Internet service business.