The Beast is Back
C++
Today
Additional
Resources
4 Easy Ways to Learn More and Stay Current
Programming Newsletter
Get programming related news and content delivered weekly to your inbox.
oreilly.com/programming/newsletter
Free Webcast Series
Learn about popular programming topics from experts live, online.
webcasts.oreilly.com
O’Reilly Radar
Read more insight and analysis about emerging technologies.
radar.oreilly.com
Conferences
Immerse yourself in learning at an upcoming O’Reilly conference.
conferences.oreilly.com
978-1-491-92758-8
[LSI] C++ Today
by Jon Kalb and Gašper Ažman
Copyright © 2015 O’Reilly Media. All rights reserved.
Printed in the United States of America.
Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472.
O’Reilly books may be purchased for educational, business, or sales promotional use. Online editions are also available for most titles (http://safaribooksonline.com). For more information, contact our corporate/institutional sales department: 800-998-9938 or corporate@oreilly.com .
Editors: Rachel Roumeliotis and Katie Schooling
Production Editor: Shiny Kalapurakkel
Proofreader: Amanda Kersey
Interior Designer: David Futato
Cover Designer: Karen Montgomery
May 2015: First Edition
Revision History for the First Edition 2015-05-04: First Release 2015-06-08: Second Release
The O’Reilly logo is a registered trademark of O’Reilly Media, Inc. C++ Today, the cover image, and related trade dress are trademarks of O’Reilly Media, Inc.
Table of Contents
Preface. . . v
1. The Nature of the Beast. . . 1
C++: What’s It Good For? 2
2. The Origin Story. . . 11
C: Portable Assembler 11
C with High-Level Abstractions 12
The ’90s: The OOP Boom, and a Beast Is Born 13
The 2000s: Java, the Web, and the Beast Nods Off 15
3. The Beast Wakes. . . 21
Technology Evolution: Performance Still Matters 21
Language Evolution: Modernizing C++ 23
Tools Evolution: The Clang Toolkit 26
Library Evolution: The Open Source Advantage 28
4. The Beast Roars Back. . . 31
WG21 31
Tools 33
Standard C++ Foundation 34
Boost: A Library and Organization 36
Q&A 37
Conferences and Groups 39
Videos 41
CppCast 42
Books 42
5. Digging Deep on Modern C++. . . 45
Type Inference: Auto and Decltype 45
How Move Semantics Support Value-Semantic and Functional Programming 48
No More Output Parameters 49
Inner Functions with Lambdas 52
Lambdas as a Scope with a Return Value 54
6. The Future of C++. . . 57
Setting the Standard 57
“Never Make Predictions, Especially About the Future” (Casey Stengel) 61
Bibliography. . . 65
Preface
This book is a view of the C++ world from two working software engineers with decades of combined experience programming in this industry. Of course this view is not omniscient, but is filled with our observations and opinions. The C++ world is vast and our space is limited, so many areas, some rather large, and others rather inter‐ esting, have been omitted. Our hope is not to be exhaustive, but to reveal a glimpse of a beast that is ever-growing and moving fast.
1When we refer to the C++ language, we mean to include the accompanying standard library. When we mean to refer to just the language (without the library), we refer to it as the core language.
CHAPTER 1
The Nature of the Beast
In this book we are referring to C++ as a “beast.” This isn’t from any lack of love or understanding; it comes from a deep respect for the power, scope, and complexity of the language,1 the monstrous size of
its installed base, number of users, existing lines of code, developed libraries, available tools, and shipping projects.
For us, C++ is the language of choice for expressing our solutions in code. Still, we would be the first to admit that users need to mind the teeth and claws of this magnificent beast. Programming in C++ requires a discipline and attention to detail that may not be required of kinder, gentler languages that are not as focused on performance or giving the programmer ultimate control over execution details. For example, many other languages allow programmers the oppor‐ tunity to ignore issues surrounding acquiring and releasing mem‐ ory. C++ provides powerful and convenient tools for handling resources generally, but the responsibility for resource management ultimately rests with the programmer. An undisciplined approach can have disastrous consequences.
Is it necessary that the claws be so sharp and the teeth so bitey? In other popular modern languages like Java, C#, JavaScript, and Python, ease of programming and safety from some forms of
2Though some C++ hobbyists go beyond most professional programmers’ day-to-day usage.
3http://www.stroustrup.com/bs_faq.html#number-of-C++-users
programmer error are a high priority. But in C++, these concerns take a back seat to expressive power and performance.
Programming makes for a great hobby, but C++ is not a hobbyist language.2 Software engineers don’t lose sight of programming ease
of use and maintenance, but when designing C++, nothing has or will stand in the way of the goal of creating a truly general-purpose programming language that can be used in the most demanding software engineering projects.
Whether the demanding requirements are high performance, low memory footprint, low-level hardware control, concurrency, high-level abstractions, robustness, or reliable response times, C++ must be able to do the job with reasonable build times using industry-standard tool chains, without sacrificing portability across hardware and OS platforms, compatibility with existing libraries, or readabil‐ ity and maintainability.
Exposure to the teeth and claws is not just the price we pay for this power and performance—sometimes, sharp teeth are exactly what you need.
C++: What’s It Good For?
C++ is in use by millions3 of professional programmers working on
millions of projects. We’ll explore some of the features and factors that have made C++ the language of choice in so many situations. The most important feature of C++ is that it is both low- and high-level. Due to that, it is able to support projects of all sizes, ensuring a small prototype can continue scaling to meet ever-increasing needs.
High-Level Abstractions at Low Cost
Well-chosen abstractions (algorithms, types, mechanisms, data structures, interfaces, etc.) greatly simplify reasoning about pro‐ grams, making programmers more productive by not getting lost in the details and being able to treat user-defined types and libraries as well-understood and well-behaved building blocks. Using them,
4For instance, one can (and people do) use virtual functions in C, but few will contest that p→vtable→foo(p) is clearer than p→foo().
5Notable peers are the D programming language, Rust, and, to a lesser extent, Google Go, albeit with a much smaller installed base.
developers are able to conceive of and design projects of much greater scope and vision.
The difference in performance between code written using high-level abstractions and code that does the same thing but is written at a much lower level4 (at a greater burden for the programmer) is
referred to as the “abstraction penalty.”
As an example: C++ introduced an I/O model based on streams. The streams model offers an interface that is, in the common case, slightly slower than using native operating system calls. However, in most cases, it is fast enough that programmers choose the superior portability, flexibility, and type-safety of streams to faster but less-friendly native calls.
C++ has features (user-defined types, type templates, algorithm templates, type aliases, type inference, compile-time introspection, runtime polymorphism, exceptions, deterministic destruction, etc.) that support level abstractions and a number of different high-level programming paradigms. It doesn’t force a specific program‐ ming paradigm on the user, but it does support procedural, object-based, object-oriented, generic, functional, and value-semantic programming paradigms and allows them to easily mix in the same project, facilitating a tailored approach for each part.
While C++ is not the only language that offers this variety of approaches, the number of languages that were also designed to keep the abstraction penalty as low as possible is far smaller.5 Bjarne
Stroustrup, the creator of C++, refers to his goal as “the zero-overhead principle,” which is to say, no abstraction penalty.
A key feature of C++ is the ability of programmers to create their own types, called user-defined types (UDTs), which can have the power and expressiveness of built-in types or fundamentals. Almost anything that can be done with a fundamental type can also be done with a user-defined type. A programmer can define a type that func‐ tions as if it is a fundamental data type, an object pointer, or even as a function pointer.
6Being a superset of C also enhances the ability of C++ to interoperate with other lan‐ guages. Because C’s string and array data structures have no memory overhead, C has become the “connecting” interface for all languages. Essentially all languages support interacting with a C interface and C++ supports this as a native subset.
C++ has so many features for making high-quality, easy to use libra‐ ries that it can be thought of as a language for building libraries. Libraries can be created that allow users to express themselves in a natural syntax and still be powerful, efficient, and safe. Libraries can be designed that have type-specific optimizations and to automati‐ cally clean up resources without explicit user calls.
It is possible to create libraries of generic algorithms and user-defined types that are just as efficient or almost as efficient as code that is not written generically.
The combination of powerful UDTs, generic programming facilities, and high-quality libraries with low abstraction penalties make pro‐ gramming at a much higher level of abstraction possible even in programs that require every last bit of performance. This is a key strength of C++.
Low-Level Access When You Need It
C++ is, among other things, a systems-programming language. It is capable of and designed for low-level hardware control, including responding to hardware interrupts. It can manipulate memory in arbitrary ways down to the bit level with efficiency on par with hand-written assembly code (and, if you really need it, allows inline assembly code). C++, from its initial design, is a superset of C,6
which was designed to be a “portable assembler,” so it has the dex‐ terity and memory efficiency to be used in OS kernels or device drivers.
One example of the kind of control offered by C++ is the flexibility available for where user-defined types can be created. Most high-level languages create objects by running a construction function to initialize the object in memory allocated from the heap. C++ offers that option, but also allows for objects to be created on the stack. Programmers have little control over the lifetime of objects created on the stack, but because their creation doesn’t require a call to the heap allocator, stack allocation is typically orders of magnitude faster. Due to its limitations, stack-based object allocation can’t be a
7http://www.drdobbs.com/parallel/eliminate-false-sharing/217500206
8For a small sample of applications and operating systems written in C++: http:// www.stroustrup.com/applications.html
general replacement for heap allocation, but in those cases where stack allocation is acceptable, C++ programmers win by avoiding the allocator calls.
In addition to supporting both heap allocation and stack allocation, C++ allows programmers to construct objects at arbitrary locations in memory. This allows the programmer to allocate buffers in which many objects can be very efficiently created and destroyed with great flexibility over object lifetimes.
Another example of having low-level control is in cache-aware cod‐ ing. Modern processors have sophisticated caching characteristics, and subtle changes in the way the data is laid out in memory can have significant impact on performance due to such factors as look-ahead cache buffering and false sharing.7 C++ offers the kind of
control over data memory layout that programmers can use to avoid cache line problems and best exploit the power of hardware. Man‐ aged languages do not offer the same kind of memory layout flexi‐ bility. Managed language containers do not hold objects in contiguous memory, and so do not exploit look-ahead cache buffers as C++ arrays and vectors do.
Wide Range of Applicability
Software engineers are constantly seeking solutions that scale. This is no less true for languages than for algorithms. Engineers don’t want to find that the success of their project has caused it to outgrow its implementation language.
Very large applications and large development teams require lan‐ guages that scale. C++ has been used as the primary development language for projects with hundreds of engineers and scores of modules.8 Its support for separate compilation of modules makes it
possible to create projects where analyzing and/or compiling all the project code at once would be impractical.
A large application can absorb the overhead of a language with a large runtime cost, either in startup time or memory usage. But to be useful in applications as diverse as device drivers, plug-ins, CGI
9“An incomplete list of C++ compilers”: http://www.stroustrup.com/compilers.html
10C++ is supported on iOS, Android, Windows Mobile, and BlackBerry: http://visualstu diomagazine.com/articles/2013/02/12/future-c-plus-plus.aspx
modules, and mobile apps, it is necessary to have as little overhead as possible. C++ has a guiding philosophy of “you only pay for what you use.” What that means is that if you are writing a device driver that doesn’t use many language features and must fit into a very small memory footprint, C++ is a viable option, where a language with a large runtime requirement would be inappropriate.
Highly Portable
C++ is designed with a specific hardware model in mind, and this model has minimalistic requirements. This has made it possible to port C++ tools and code very broadly, as machines built today, from nanocomputers to number-crunching behemoths, are all designed to implement this hardware model.
There are one or more C++ tool chains available on almost all com‐ puting platforms.9 C++ is the only high-level language alternative
available on all of the top mobile platforms.10
Not only are the tools available, but it is possible to write portable code that can be used on all these platforms without rewriting. With the consideration of tool chains, we have moved from lan‐ guage features to factors outside of the language itself. But these fac‐ tors have important engineering considerations. Even a language with perfect syntax and semantics wouldn’t have any practical value if we couldn’t build it for our target platform.
In order for an engineering organization to seriously consider sig‐ nificant adoption of a language, it needs to consider availability of tools (including analyzers and other non-build tools), experienced engineers, software libraries, books and instructional material, trou‐ bleshooting support, and training opportunities.
Extra-language factors, such as the installed user base and industry support, always favor C++ when a systems language is required and tend to favor C++ when choosing a language for building large-scale applications.
11It would be hard to over-emphasize how costly these problems have been in non-garbage collected languages.
Better Resource Management
In the introduction to this chapter, we discussed that other popular languages prioritize ease of programming and safety over perfor‐ mance and control. Nothing is a better example of the differences between these languages and C++ than their approaches to memory management.
Most popular modern languages implement a feature called garbage collection, or GC. With this approach to memory management, the programmer is not required to explicitly release allocated memory that is no longer needed. The language runtime determines when memory is “garbage” and recycles it for reuse. The advantages to this approach may be obvious. Programmers don’t need to track mem‐ ory, and “leaks” and “double dispose” problems11 are a thing of the
past.
But every design decision has trade-offs, and GC is no exception. One issue with it is that collectors don’t recognize that memory has become garbage immediately. The recognition that memory needs to be released will happen at some unspecified future time (and for some, implementations may not happen at all—if, for example, the application terminates before it needs to recycle memory).
Typically, the collector will run in the background and decide when to recycle memory outside of the programmer’s control. This can result in the foreground task “freezing” while the collector recycles. Since memory is not recycled as soon as it is no longer needed, it is necessary to have an extra cushion of memory so that new memory can be allocated while some unneeded memory has not yet been recycled. Sometimes the cushion size required for efficient operation is not trivial.
An additional objection to GC from a C++ point of view is that memory is not the only resource that needs to be managed. Pro‐ grammers need to manage file handles, network sockets, database connections, locks, and many other resources. Although we may not be in a big hurry to release memory (if no new memory is being requested), many of these other resources may be shared with other
12It may also stand for Responsibility Acquisition Is Initialization when the concept is extended beyond just resource management.
processes and need to be released as soon as they are no longer needed.
To deal with the need to manage all types of resources and to release them as soon as they can be released, best-practice C++ code relies on a language feature called deterministic destruction.
In C++, one way that objects are instantiated by users is to declare them in the scope of a function, causing the object to be allocated in the function’s stack frame. When the execution path leaves the func‐ tion, either by a function return or by a thrown exception, the local objects are said to have gone out of scope.
When an object goes out of scope, the runtime “cleans up” the object. The definition of the language specifies that objects are cleaned up in exactly the reverse order of their creation (reverse order ensures that if one object depends on another, the dependent is removed first). Cleanup happens immediately, not at some unspe‐ cified future time.
As we pointed out earlier, one of the key building blocks in C++ is the user-defined type. One of the options programmers have when defining their own type is to specify exactly what should be done to “clean up” an object of the defined type when it is no longer needed. This can be (and in best practice is) used to release any resources held by the object. So if, for example, the object represents a file being read from or written to, the object’s cleanup code can auto‐ matically close the file when the object goes out of scope.
This ability to manage resources and avoid resource leaks leads to a programming idiom called RAII, or Resource Acquisition Is Initiali‐ zation.12 The name is a mouthful, but what it means is that for any
resource that our program needs to manage, from file handles to mutexes, we define a user type that acquires the resource when it is initialized and releases the resource when it is cleaned up.
To safely manage a particular resource, we just declare the appropri‐ ate RAII object in the local scope, initialized with the resource we need to manage. The resource is guaranteed to be cleaned up exactly once, exactly when the managing object goes out of scope, thus solv‐
13http://www.lextrait.com/vincent/implementations.html
14Independent software vendors, the people that sell commercial applications for money. Like the creators of Office, Quicken, and Photoshop.
ing the problems of resource leaks, dangling pointers, double relea‐ ses, and delays in recycling resources.
Some languages address the problem of managing resources (other than memory) by allowing programmers to add a finally block to a scope. This block is executed whenever the path of execution leaves the function, whether by function return or by thrown excep‐ tion. This is similar in intent to deterministic destruction, but with this approach, every function that uses an object of a particular resource managing type would need to have a finally block added to the function. Overlooking a single instance of this would result in a bug.
The C++ approach, using RAII, has all the convenience and clarity of a garbage-collected system, but makes better use of resources, has greater performance and flexibility, and can be used to manage resources other than memory. Generalizing resource management instead of just handling memory is a strong advantage of this approach over garbage collection and is the reason that most C++ programmers are not asking that GC be added to the language.
Industry Dominance
C++ has emerged as the dominant language in a number of diverse product categories and industries.13 What these domains have in
common is either a need for a powerful, portable systems-programming language or an application-systems-programming language with uncompromising performance. Some domains where C++ is dominant or near dominant include search engines, web browsers, game development, system software and embedded computing, automotive, aviation, aerospace and defense contracting, financial engineering, GPS systems, telecommunications, video/audio/image processing, networking, big science projects, and ISVs.14
1http://cm.bell-labs.co/who/dmr/chist.html
CHAPTER 2
The Origin Story
This may be old news to some readers, and is admittedly a C++-centric telling, but we want to provide a sketch of the history of C++ in order to put its recent resurgence in perspective.
The first programming languages, such as Fortran and Cobol, were developed to allow a domain specialist to write portable programs without needing to know the arcane details of specific machines. But systems programmers were expected to master such details of computer hardware, so they wrote in assembly language. This gave programmers ultimate power and performance at the cost of porta‐ bility and tedious detail. But these were accepted as the price one paid for doing systems programming.
The thinking was that you either were a domain specialist, and therefore wanted or needed to have low-level details abstracted from you, or you were a systems programmer and wanted and needed to be exposed to all those details. The systems-programming world was ripe for a language that allowed to you ignore those details except when access to them was important.
C: Portable Assembler
In the early 1970s, Dennis Ritchie introduced “C,”1 a programming
language that did for systems programmers what earlier high-level
languages had done for domain specialists. It turns out that systems programmers also want to be free of the mind-numbing detail and lack of portability inherent in assembly-language programming, but they still required a language that gave them complete control of the hardware when necessary.
C achieved this by shifting the burden of knowing the arcane details of specific machines to the compiler writer. It allowed the C pro‐ grammer to ignore these low-level details, except when they mat‐ tered for the specific problem at hand, and in those cases gave the programmer the control needed to specify details like memory lay‐ outs and hardware details.
C was created at AT&T’s Bell Labs as the implementation language for Unix, but its success was not limited to Unix. As the portable assembler, C became the go-to language for systems programmers on all platforms.
C with High-Level Abstractions
As a Bell Labs employee, Bjarne Stroustrup was exposed to and appreciated the strengths of C, but also appreciated the power and convenience of higher-level languages like Simula, which had lan‐ guage support for object-oriented programming (OOP).
Stroustrup realized that there was nothing in the nature of C that prevented it from directly supporting higher-level abstractions such as OOP or type programming. He wanted a language that provided programmers with both elegance when expressing high-level ideas and efficiency of execution size and speed.
He worked on developing his own language, originally called C With Classes, which, as a superset of C, would have the control and power of portable assembler, but which also had extensions that supported the higher-level abstractions that he wanted from Simula.
[DEC]
The extensions that he created for what would ultimately become known as C++ allowed users to define their own types. These types could behave (almost) like the built-in types provided by the lan‐ guage, but could also have the inheritance relationships that sup‐ ported OOP.
2http://www.open-std.org/jtc1/sc22/wg21/
3Most language creators retain control of their creation or give them to standards bodies and walk away. Stroustrup’s continuing to work on C++ as part of the ISO is a unique situation.
He also introduced templates as a way of creating code that could work without dependence on specific types. This turned out to be very important to the language, but was ahead of its time.
The ’90s: The OOP Boom, and a Beast Is Born
Adding support for OOP turned out to be the right feature at the right time for the ʽ90s. At a time when GUI programming was all the rage, OOP was the right paradigm, and C++ was the right imple‐ mentation.
Although C++ was not the only language supporting OOP, the tim‐ ing of its creation and its leveraging of C made it the mainstream language for software engineering on PCs during a period when PCs were booming.
The industry interest in C++ became strong enough that it made sense to turn the definition of the language over from a single indi‐ vidual (Stroustrup) to an ISO (International Standards Organiza‐ tion) Committee.2 Stroustup continued to work on the design of the
language and is an influential member of the ISO C++ Standards Committee to this day.3
In retrospect, it is easy to see that OOP, while very useful, was over-hyped. It was going to solve all our software engineering problems because it would increase modularity and reusability. In practice, reusability goes up within specific frameworks, but these frame‐ works introduce dependencies, which reduce reusability between frameworks.
Although C++ supported OOP, it wasn’t limited to any single para‐ digm. While most of the industry saw C++ as an OOP language and was building its popularity and installed base using object frame‐ works, others where exploiting other C++ features in a very differ‐ ent way.
Alex Stepanov was using C++ templates to create what would even‐ tually become known as the Standard Template Library (STL). Ste‐ panov was exploring a paradigm he called generic programming. Generic programming is “an approach to programming that focuses on designing algorithms and data structures so that they work in the most general setting without loss of efficiency.” [FM2G]
Although the STL was a departure from every other library at the time, Andrew Koenig, then the chair of the Library Working Group for the ISO C++ Standards Committee, saw the value in it and invi‐ ted Stepanov to make a submission to the committee. Stepanov was skeptical that the committee would accept such a large proposal when it was so close to releasing the first version of the standard. Koenig asserted that Stepanov was correct. The committee would not accept it…if Stepanov didn’t submit it.
Stepanov and his team created a formal specification for his library and submitted it to the committee. As expected, the committee felt that it was an overwhelming submission that came too late to be accepted.
Except that it was brilliant!
The committee recognized that generic programming was an important new direction and that the STL added much-needed functionality to C++. Members voted to accept the STL into the standard. In its haste, it did trim the submission of a number of fea‐ tures, such as hash tables, that it would end up standardizing later, but it accepted most of the library.
By accepting the library, the committee introduced generic pro‐ gramming to a significantly larger user base.
In 1998, the committee released the first ISO standard for C++. It standardized “classic” C++ with a number of nice improvements and included the STL, a library and programming paradigm clearly ahead of its time.
One challenge that the Library Working Group faced was that it was tasked not to create libraries, but to standardize common usage. The problem it faced was that most libraries were either like the STL (not in common use) or they were proprietary (and therefore not good candidates for standardization).
4http://www.boost.org/users/proposal.pdf
5http://boost.org/
6https://sfconservancy.org/
Also in 1998, Beman Dawes, who succeeded Koenig as Library Working Group chair, worked with Dave Abrahams and a few other members of the Library Working Group to set up the Boost Libra‐ ries.4 Boost is an open source, peer-reviewed collection of C++ libra‐
ries,5 which may or may not be candidates for inclusion in the
standard.
Boost was created so that libraries that might be candidates for standardization would be vetted (hence the peer reviews) and popu‐ larized (hence the open source).
Although it was set up by members of the Standards Committee with the express purpose of developing candidates for standardiza‐ tion, Boost is an independent project of the nonprofit Software Freedom Conservancy.6
With the release of the standard and the creation of Boost.org, it seemed that C++ was ready to take off at the end of the ʽ90s. But it didn’t work out that way.
The 2000s: Java, the Web, and the Beast
Nods Off
At over 700 pages, the C++ standard demonstrated something about C++ that some critics had said about it for a while: C++ is a compli‐ cated beast.
The upside to basing C++ on C was that it instantly had access to all libraries written in C and could leverage the knowledge and famili‐ arity of thousands of C programmers.
But the downside was that C++ also inherited all of C’s baggage. A lot of C’s syntax and defaults would probably be done very differ‐ ently if it were being designed from scratch today.
Making the more powerful user-defined types of C++ integrate with C so that a data structure defined in C would behave exactly the same way in both C and C++ added even more complexity to the language.
7“Build once, run anywhere,” while still often not the case with Java, is sometimes much more useful for deployment than the “write once, build anywhere” type of portability of C++.
The addition of a streams-based input/output library made I/O much more OOP-like, but meant that the language now had two complete and completely different I/O libraries.
Adding operator overloading to C++ meant that user-defined types could be made to behave (almost) exactly like built-in types, but it also added complexity.
The addition of templates greatly expanded the power of the lan‐ guage, but at no small increase in complexity. The STL was an exam‐ ple of the power of templates, but was a complicated library based on generic programming, a programming paradigm that was not appreciated or understood by most programmers.
Was all this complexity worth it for a language that combined the control and performance of portable assembler with the power and convenience of high-level abstractions? For some, the answer was certainly yes, but the environment was changing enough that many were questioning this.
The first decade of the 21st century saw desktop PCs that were pow‐ erful enough that it didn’t seem worthwhile to deal with all this com‐ plexity when there were alternatives that offered OOP with less complexity.
One such alternative was Java.
As a bytecode interpreted, rather than compiled, language, Java couldn’t squeeze out all the performance that C++ could, but it did offer OOP, and the interpreted implementation was a powerful fea‐ ture in some contexts.7
Because Java was compiled to bytecode that could be run on a Java virtual machine, it was possible for Java applets to be downloaded and run in a web page. This was a feature that C++ could only match using platform-specific plug-ins, which were not nearly as seamless.
So Java was less complex, offered OOP, was the language of the Web (which was clearly the future of computing), and the only downside
8Java’s “references” can be null, and can be re-bound, so they are pointers; you just can’t increment them.
was that it ran a little more slowly on desktop PCs that had cycles to spare. What’s not to like?
Java’s success led to an explosion of what are commonly called man‐ aged languages. These compile into bytecode for a virtual machine with a just-in-time compiler, just like Java. Two large virtual machines emerged from this explosion. The elder, Java Virtual Machine, supports Java, Scala, Jython, Jruby, Clojure, Groovy, and others. It has an implementation for just about every desktop and server platform in existence, and several implementations for some of them. The other, the Common Language Interface, a Microsoft virtual machine, with implementations for Windows, Linux, and OS X, also supports a plethora of languages, with C#, F#, IronPython, IronRuby, and even C++/CLI leading the pack.
Colleges soon discovered that managed languages were both easier to teach and easier to learn. Because they don’t expose the full power of pointers8 directly to programmers, it is less elegant, and some‐
times impossible, to do some things that a systems programmer might want to do, but it also avoids a number of nasty programming errors that have been the bane of many systems programmers’ exis‐ tence.
While things were going well for Java and other managed languages, they were not going so well for C++.
C++ is a complicated language to implement (much more than C, for example), so there are many fewer C++ compilers than there are C compilers. When the Standards Committee published the first C++ standard in 1998, everyone knew that it would take years for the compiler vendors to deliver a complete implementation.
The impact on the committee itself was predictable. Attendance at Standards Committee meetings fell off. There wasn’t much point in defining an even newer version of the standard when it would be a few years before people would begin to have experience using the current one.
About the time that compilers were catching up, the committee released the 2003 standard. This was essentially a “bug fix” release
9http://accu.org/index.php/aboutus
with no new features in either the core language or the standard library.
After this, the committee released the first and only C++ Technical Report, called TR1. A technical report is a way for the committee to tell the community that it considers the content as standard-candidate material.
The TR1 didn’t contain any change to the core language, but defined about a dozen new libraries. Almost all of these were libraries from Boost, so most programmers already had access to them.
After the release of the TR1, the committee devoted itself to releas‐ ing a new update. The new release was referred to as “0x” because it was obviously going to be released sometime in 200x.
Only it wasn’t. The committee wasn’t slacking off—they were adding a lot of new features. Some were small nice-to-haves, and some were groundbreaking. But the new standard didn’t ship until 2011. Long, long overdue.
The result was that although the committee had been working hard, it had released little of interest in the 13 years from 1998 to 2011. We’ll use the history of one group of programmers, the ACCU, to illustrate the rise and fall of interest in C++. In 1987, The C Users Group (UK) was formed as an informal group for those who had an interest in the C language and systems programming. In 1993, the group merged with the European C++ User Group (ECUG) and continued as the Association of C and C++ Users.
By the 2000s, members were interested in languages other than C and C++, and to reflect that, the group changed its name to just the initials ACCU. Although the group is still involved in and support‐ ing C++ standardization, its name no longer stands for C++, and members are also exploring other languages, especially C#, Java, Perl, and Python.9
By 2010, C++ was still in use by millions of engineers, but the excitement of the ʽ90s had faded. There had been over a decade with few enhancements released by the Standards Committee. Colleges and the cool kids were defecting to Java and managed languages. It looked like C++ might just turn into another legacy-only beast like Cobol.
But instead, the beast was just about to roar back.
CHAPTER 3
The Beast Wakes
In this chapter and the next, we are going to be exploring the factors that drove interest back to C++ and the community’s response to this growing interest. However, we’d first like to point out that, par‐ ticularly for the community responses, this isn’t entirely a one-way street. When a language becomes more popular, people begin to write and talk about it more. When people write and talk about a language more, it generates more interest.
Debating the factors that caused the C++ resurgence versus the fac‐ tors caused by it isn’t the point of this book. We’ve identified what we think are the big drivers and the responses, but let’s not forget that these responses are also factors that drive interest in C++.
Technology Evolution: Performance Still
Matters
Performance has always been a primary driver in software develop‐ ment. The powerful desktop machines of the 2000s didn’t signal a permanent change in our desire for performance; they were just a temporary blip.
Although powerful desktop machines continue to exist and will remain very important for software development, the prime targets for software development are no longer on the desk (or in your lap). They are in your pocket and in the cloud.
1C++ is not necessarily the recommended language on mobile platforms but is supported in one way or another.
2http://perspectives.mvdirona.com/2010/09/overall-data-center-costs/
Modern mobile devices are very powerful computers in their own right, but they have a new concern for performance: performance per watt. For a battery-powered mobile device, there is no such thing as spare cycles.
Earlier we pointed out that C++ is the only high-level language available1 for all mobile devices running iOS, Android, or Windows.
Is this because Apple, which adopted Objective-C and invented Swift, is a big fan of C++? Is it because Google, which invented Go and Dart, is a big fan of C++? Is it because Microsoft, which inven‐ ted C#, is a big fan of C++? The answer is that these companies want their devices to feature apps that are developed quickly, but are responsive and have long battery life. That means they need to offer developers a language with high-level abstraction features (for fast development) and high performance. So they offer C++.
Cloud-based computers, that is, computers in racks of servers in some remote data center, are also powerful computers, but even there we are concerned about performance per watt. In this case, the concern isn’t dead batteries, but power cost. Power to run the machines, and power to cool them.
The cloud has made it possible to build enormous systems spanning hundreds, thousands, or tens of thousands of machines bound to a single purpose. A modest improvement in speed at those scales can represent substantial savings in infrastructure costs.
James Hamilton, a vice president and distinguished engineer on the Amazon Web Services team, reported on a study he did of modern high-scale data centers.2 He broke the costs down into (in decreasing
order of significance) servers, power distribution & cooling, power, networking equipment, and other infrastructure. Notice that the top three categories are all directly related to software performance, either performance per hardware investment or performance per watt. Hamilton determined that 88% of the costs are dependent on performance. A 1% performance improvement in code will almost produce a 1% cost savings, which for a data center at scale will be a significant amount of money.
3To the extent that such languages are being used for prototyping, to bring features to market quickly, or for software that doesn’t need to run at scale, there is still a role for these languages. But it isn’t in data centers at scale.
4And much appreciated. In a 2015 survey, Stack Overflow found that C++11 was the second “most loved” language of its users (after newcomer Swift). http://stackover flow.com/research/developer-survey-2015
5https://isocpp.org/tour
For companies with server farms the size of Amazon, Facebook, Google, or Microsoft, not using C++ is an expensive alternative. But how is this different from how computing in large enterprise companies has always been done? Look again at the list of expense categories. Programmers and IT professionals are not listed. Did Hamilton forget them? No. Their cost is in the noise. Managed lan‐ guages that have focused on programmer productivity at the expense of performance are optimizing for a cost not found in the modern scaled data center.3
Performance is back to center stage, and with it is an interest in C++ for both cloud and mobile computing. For mobile computing, the “you only pay for what you use” philosophy and the ability to run in a constrained memory environment are additional wins. For cloud computing, the fact that C++ is highly portable and can run effi‐ ciently and reliably on a wide variety of low-cost hardware are addi‐ tional wins, especially because one can tune directly for the hardware one owns.
Language Evolution: Modernizing C++
In 2011, the first major revision to Standard C++ was released, and it was very clear that the ISO Committee had not been sitting on its hands for the previous 13 years. The new standard was a major update to both the core language and the standard library.4
The update, which Bjarne Stroustrup, the creator of C++, reported “feels like a new language,”5 seemed to offer something for everyone.
It had dozens of changes, some small and some fundamental, but the most important achievement was that C++ now had the features programmers expected of a modern language.
The changes were extensive. The page count of the ISO Standard went from 776 for the 2003 release to 1,353 for the 2011 release. It
6http://en.wikipedia.org/wiki/C%2B%2B11
isn’t our purpose here to catalogue them all. Other references are available for that.6 Instead, we’ll just give some idea about the kinds
of changes.
One of the most important themes of the release was simplifying the language. No one would like to “tame the beast” of its complexity more than the Standards Committee. The challenge that the com‐ mittee faces is that it can’t remove anything already in the standard because that would break existing code. Breaking existing code is a nonstarter for the committee.
It may not seem possible to simplify by adding to an already compli‐ cated specification, but the committee found ways to do exactly that. It addressed some minor annoyances and inconsistencies, and added the ability to have the compiler deduce types in situations where the programmer used to have to spell them out explicitly. It added a new version of the “for” statement that would automatically iterate over containers and other user-defined types.
It made enumeration and initialization syntax more consistent, and added the ability to create functions that take an arbitrary number of parameters of a specified type.
It has always been possible in C++ to define user-defined types that can hold state and be called like functions. However, this ability has been underutilized because the syntax for creating user-defined types for this purpose was verbose, was hardly obvious, and as such added some inconvenient overhead. The new language update intro‐ duced a new syntax for defining and instantiating function objects (lambdas) to make them convenient to use. Lambdas can also be used as closures, but they do not automatically capture the local scope—the programmer has to specify what to capture explicitly. The 2011 update added better support for character sets, in particu‐ lar, better support for Unicode. It standardized a regular expression library (from Boost via the TR1) and added support for “raw” liter‐ als that makes working with regular expressions easier.
The standard library was significantly revised and extended. Almost all of the libraries defined in the TR1 were incorporated into the standard. Types that were already defined in the standard library,
7Implemented as templated using aliases.
8Through a plethora of new type-traits and subtle corrections to the SFINAE rules. Sub‐ stitution Failure is not an Error is an important rule for finding the correct template to instantiate, when more than one appears to match initially. It allows for probing for capabilities of types, since using a capability that isn’t offered will just try a different template.
such as STL containers, were updated to reflect new core language features; and new containers, such as a singly-linked list and hash-based associative containers, were added.
All of these features were additions to the language specification, but had the effect of making the language simpler to learn and use for everyday programming.
Reflecting that C++ is a language for library building, a number of new features made life easier for library authors. The update intro‐ duced language support for “perfect forwarding.” Perfect forwarding
refers to the ability of a library author to capture a set of parameters to a function and “forward” these to another function without changing anything about the parameters. Boost library authors had demonstrated that this was achievable in classic C++, but only with great effort and language mastery.
Now, mere mortals can implement libraries using perfect forward‐ ing by taking advantage of a couple of features new in the 2011 update: variadic templates and rvalue references.
A richer type system allows better modeling of requirements that can be checked at compile time, catching wide classes of bugs auto‐ matically. The tighter the type system models the problem, the harder it is for bugs to slip through the cracks. It also often makes it easier for compilers to prove additional invariants, enabling better automatic code optimization. New features aimed at library builders included better support for type functions.7
Better support for compile-time reflection of types8 enables library
writers to adapt their libraries to wide varieties of user types, using the optimal algorithms for the capabilities the user’s objects expose without additional burden on the users of the library.
The update also broke ground in some new areas. Writing multi‐ threaded code in C++ has been possible, but only with the use of platform-specific libraries. With the concurrency support intro‐
9C, C++, Objective-C, and Objective-C++
duced in the 2011 update, it is now possible to write multithreaded code and libraries in a portable way.
This update also introduced move semantics, which Scott Meyers referred to as the update’s “marquee feature.” Avoiding unnecessary copies is a constant challenge for programmers who are concerned about performance, which C++ programmers almost always are. Because of the power and flexibility of “classic” C++, it has always been possible to avoid unnecessary copies, but sometimes this was at the cost of code that took longer to write, was less readable, and was harder to reuse.
Move semantics allow programmers to avoid unnecessary copies with code that is straightforward in both writing and reading. Move semantics are a solution to an issue (unnecessary copies) that C++ programmers care about, but is almost unnoticed in other language environments.
This isn’t a book on how to program. Our goal is to talk about C++, not teach it. But we can’t help ourselves, we want to show what modern C++ really means, so if you are interested in code examples of how C++ is evolving, don’t skip Chapter 5, Digging Deep on Modern C++.
As important as it was to have a new standard, it wouldn’t have had any meaningful impact if there were no tools that implemented it.
Tools Evolution: The Clang Toolkit
Due to its age and the size of its user base, there are many tools for C++ on many different platforms. Some are proprietary, some are free, some are open source, some are cross-platform. There are too many to list, and that would be out of scope for us here. We’ll dis‐ cuss a few interesting examples.
Clang is the name of a compiler frontend for the C family of lan‐ guages.9 Although it was first released in 2007, and its code genera‐
tion reached production quality for C and Objective-C later that decade, it wasn’t really interesting for C++ until this decade.
10For some CPUs and/or code cases, it has caught up or passed its competitors.
11Some examples comparing error messages from Clang with old and newer versions of GCC: https://gcc.gnu.org/wiki/ClangDiagnosticsComparison
Clang is interesting to the C++ community for two reasons. The first is that it is a new C++ compiler. Due to its wide feature-set and a few syntactic peculiarities that make it very hard to parse, new C++ frontends don’t come along everyday. But more than just being an alternative, its value lay in its much more helpful error messages and significantly faster compile times.
As a newer compiler, Clang is still catching up with older compilers on the performance of generated code10 (which is usually of primary
consideration for C++ programmers). But its better build time and error messages increase programmer productivity. Some developers have found a best-of-both-worlds solution by using Clang for the edit-build-test-debug cycle, but build production releases with an older compiler. For developers using GCC, this is facilitated by Clang’s desire to be “drop in” compatible with GCC. Clang brought some helpful competition to the compiler space, making GCC also improve significantly. This competition is benefiting the community immensely.
One result of the complexity of C++ is that compile-time error mes‐ sages can sometimes be frustratingly inscrutable, particularly where templates are involved. Clang established its reputation as a C++ compiler by generating error messages that were more understanda‐ ble and more useful to programmers. The impact that Clang’s error messages have had on the industry can be seen in how much other compilers have improved their own.11
The second reason that Clang is interesting to the C++ community is because it is more than just a compiler; it is an open source toolkit that is itself implemented in high-quality C++. Clang is factored to support the building of development tools that “understand” C++.
Clang contains a static analysis framework, which the clang-tidy tool uses. Writing additional checkers for the framework is quite simple. Using the Clang toolkit, programmers can build dynamic analyzers, source-to-source translators, refactoring tools, or make any number of other kinds of tools.
12http://clang.llvm.org/docs/AddressSanitizer.html
13http://clang.llvm.org/docs/MemorySanitizer.html
14http://clang.llvm.org/docs/LeakSanitizer.html
15http://clang.llvm.org/docs/ThreadSanitizer.html
16https://metashell.readthedocs.org/en/latest/
17http://lcamtuf.coredump.cx/afl/
18https://dxr.readthedocs.org/en/latest/
19Clang and its standard library implementation, libc++, are usually the first compiler and library to implement new C++ features.
There are a number of dynamic analyzers that come built into Clang: AddressSanitizer,12 MemorySanitizer,13 LeakSanitizer,14 and
ThreadSanitizer.15 The compile time flag -fdocumentation will look
for Doxygen-style comments and warn you if the code described doesn’t match the comments.
Metashell16 is an interactive environment for template metaprog‐
ramming. American fuzzy lop17 is a security-oriented fuzzer that
uses code-coverage information from the binary under test to guide its generation of test cases. Mozilla has built a source code indexer for large code bases called DXR.18
Over time, the performance of Clang’s generated code will improve, but the importance of that will pale compared to the impact on the community of the tools that will be built from the Clang toolkit. We’ll see more and more tools for understanding, improving, and verifying code as well as have a platform for trying out new core lan‐ guage features.19
Library Evolution: The Open Source Advantage
The transition to a largely open source world has benefited C++ rel‐ ative to managed languages, but especially Java. This came from two sources. First, shipping source code further improved runtime-performance of C++; and second, the availability of source reduced the advantage of Java’s “build once, run anywhere” deployment story, since “write once, build for every platform” became viable. The model used by most proprietary libraries was for the library vendor to ship library headers and compiled object files to applica‐ tion developers. Among the implications of this are the fact that this limits the portability options available to application developers.
20The JIT has the ability to see the entire application. This allows for optimizations that would not be possible to a compiler linking to compiled library object files. Today’s C++ compilers use link-time (or whole-program) optimization features to achieve these optimizations. This requires that object files be compiled to support this feature. On the other hand, the JIT compiler was hampered by the very dynamic nature of Java, which forbade most of the optimizations the C++ compiler can do.
Library vendors can’t provide object files for every possible hard‐ ware/OS platform combination, so inevitably practical limits pre‐ vented applications from being offered on some platforms because required libraries were not readily available.
Another implication is that library vendors, again for obvious prac‐ tical reasons, couldn’t provide library object files compiled with every combination of compiler settings. This would mean the final application was almost always suboptimal in the way that their libra‐ ries were compiled.
One particular issue here is processor-specific compilation. Pro‐ cessor families have a highly compatible instruction set that all new processors support for backward compatibility. But new processors often add new instructions to enable their new features. Processors also vary greatly in their pipeline architectures, which can make code that performs well on one processor less desirable on another. Compiling for a specific processor is therefore highly desirable. This fact had worked in Java’s favor. Earlier we referred to Java as an interpreted language, which is true to a first approximation, but managed languages are implemented with a just-in-time compiler that can enhance performance over what would be possible by strictly interpreting bytecode.20 One way that the JIT can enhance
performance is to compile for the actual processor on which it is running.
A C++ library provider would tend to provide a library object com‐ piled to the “safe,” highly-compatible instruction set, rather than have to supply a number of different object files, one for each possi‐ ble processor. Again, this would often result in suboptimal perfor‐ mance.
But we no longer live in a world dominated by proprietary libraries. We live in an open source world. The success and influence of the Boost libraries contributed to this, but the open source movement has been growing across all languages and platforms. The fact that
libraries are now available as source code means that developers can target any platform with any compiler and compiler options that they choose, and support optimizations that require the source. Cloud computing only reinforces this advantage. In a cloud com‐ puting scenario, developers can target their own hardware with cus‐ tom builds that free the compiler to optimize for the particular target processor.
Closed-source libraries also forced library vendors to eschew the use of templates, instead relying on runtime dispatch and object-oriented programming, which is slower and harder to make type-safe. This effectively barred them from using some of the most powerful features of C++. These days, vending template libraries with barely any compiled objects is the norm, which tends to make C++ a much more attractive proposition.
1https://isocpp.org/std/the-committee
CHAPTER 4
The Beast Roars Back
In this chapter, we’ll discuss a number of C++ resources, most of which are either new or have been revitalized in the last few years. Of course this isn’t an exhaustive list. Google and Amazon are your friends.
WG21
Our first topic is the ISO Committee for C++ standardization, which at 25 years old, is hardly a new resource, but it certainly glows with new life. The committee is formally called ISO/IEC JTC1 (Joint Technical Committee 1) / SC22 (Subcommittee 22) / WG21 (Work‐ ing Group 21).1 Now you know why most people just call it the C++
Standards Committee.
As big an accomplishment as it is to release a new or updated major standard like C++98 or C++11, it doesn’t have much practical impact if there are no tools that implement it. As mentioned earlier, this was a significant issue with the release of the standard in 1998. Committee attendance fell off because implementation was under‐ stood to be years away.
But this was not the case for the release in 2011. Tool vendors had been tracking the standard as it was being developed. Although it called for significant changes to both the core language and the stan‐
2Note the weasel words “substantially” and “soon.” Complete and bug-free implementa‐ tions of every feature aren’t the point here. The crux is that the community recognized that C++11 was a real thing and the need to get on board right away.
3We are looking at you, Python 3.0.
4Or, in the case of some features, preceded.
5The meeting where a new standard is officially voted to be a release is always highly attended. The first few meetings after that did see a bit of a drop, but soon the upward trend was clear.
6https://isocpp.org/std/the-committee
dard library, the new update was substantially implemented by a couple of different open source implementations, GCC and Clang, soon after its release.2 Other tool vendors had also demonstrated
their commitment to the update. Unlike some language updates,3
this was clearly adopted by the entire community as the path for‐ ward.
The psychological impact of this should not be underestimated. Thirteen years is a very long time in the world of programming lan‐ guages. Some people had begun to think of C++ as an unchanging definition, like chess or Latin. The update changed the perception of C++ from a dying monster of yesteryear into a modern, living crea‐ ture.
The combination of seeing C++ as a living creature, and one where implementations closely followed4 standardization, meant that
Standards Committee meeting attendance began to increase.5
The committee reformulated itself6 to put the new members to the
best use. It had long been formed of a set of subcommittees called working groups. There were Core, Library, and Evolution working groups; but with many new members and so many areas in which the industry is asking for standardization, new working groups were the answer. The Committee birthed over a dozen new “Domain Spe‐ cific Investigation & Development” groups.
The first new product of the committee was a new standard in 2014. C++14 was not as big a change as C++11, but it did significantly improve some of the new features in C++11 by filling in the gaps discovered with real-world experience using these new features. The target for the next standard release is 2017. The working groups are busy reviewing and developing suggestions that may or may not become part of the next update.
7https://www.biicode.com/
8http://undo-software.com/
9https://www.jetbrains.com/
10https://www.jetbrains.com/clion/
The existence of a vital Standards Committee that is engaged with the language users, tool vendors, and educators is a valuable resource. Actively discussing and debating possible features is a healthy process for the entire community.
In Chapter 6, The Future of C++, we’ll discuss more about the work‐ ing groups and what they are working on.
Tools
Clang is clearly the most significant new development in the C++ toolchain, but the resurgence of interest in C++ has brought more than just Clang to the community. We’ll discuss a few interesting newcomers.
biicode7 is a cross-platform dependency manager that you can use to
download, configure, install, and manage publicly available libraries, like the Boost libraries. This is old-hat for other languages, but this is new technology for C++. The site only hit 1.0 in the middle of 2014 and is still in beta, but it has thousands of users and has been growing aggressively.
Undo Software8 has a product called UndoDB, which is a reversible
debugger. The idea of a reversible debugger, one that supports step‐ ping backward in time, is so powerful that it has been implemented many times. The problem with previous implementations is that they run so slowly and require so much data collection that they aren’t practical for regular use. Undo has found a way to increase the speed and reduce the data requirements so that the approach is practical for the first time. This product isn’t C++ only, but its mar‐ keting is focused on the C++ community.
JetBrains9 has built its reputation on IDEs with strong refactoring
features and has over a dozen products for developers. But until launching CLion10 in 2015, it’s not had a C++ product. CLion is a
cross-platform IDE for C and C++ with support for biicode. CLion can be used on Windows, but for developers that use Microsoft’s
11https://www.jetbrains.com/resharper/
12http://osv.io/
13http://osv.io/frequently-asked-questions/
14Consider Java, JavaScript, C#, Objective-C.
15It gave the rights to the C++ manual to the ISO. http://www.stroustrup.com/ bs_faq.html#revenues
16The only central organization for C++ was the Standards Committee, but promoting the language was outside of its charter (and resources).
Visual Studio for C++ development, JetBrains is updating ReSharper,11 its VS extension, which supports C#, .NET, and
web-development languages to also support C++.
The last tool that we’ll mention isn’t a development tool, but a deployment tool. OSv12 is an operating system written in C++ that is
optimized for use in the cloud. By rethinking the requirements of a virtual machine existing in the cloud, Cloudius Systems has created an OS with reduced memory and CPU overhead and lightweight scheduling. Why was this implemented in C++ instead of C? It turns out that gets asked a lot:
While C++ has a deserved reputation for being incredibly compli‐ cated, it is also incredibly rich and flexible, and in particular has a very flexible standard library as well as add-on libraries such as boost. This allows OSV code to be much more concise than it would be if it were written in C, while retaining the close-to-the-metal efficiency of C.13
—OSv FAQ
Standard C++ Foundation
Many languages14 are either created by or adopted by a large com‐
pany that considers the adoption of the language by others a strate‐ gic goal and so markets and promotes the language. Although AT&T was supportive of C++,15 it never “marketed” the language to
encourage adoption by external developers.
Various tool vendors and publishers have promoted C++ tools or books, but until this decade, no organization16 has marketed C++
itself. This didn’t seem to be an impediment to the growth and acceptance of the language. But in 2010, as the committee was about to release the largest update to the standard since it was created,
17“Convener” is ISO speak for committee chair.
18http://isocpp.org/about/
19https://isocpp.org/faq
20http://www.stroustrup.com/
21The concept and term “FAQ” was invented by Usenet group moderators.
22http://www.amazon.com/FAQs-2nd-Marshall-P-Cline/dp/0201309831/
23https://isocpp.org/get-started
24https://isocpp.org/wiki/faq/user-groups-worldwide
interest in C++ had noticeably increased. The time seemed ripe for a central place for C++-related information.
At least it seemed like a good idea to Herb Sutter, the Standards Committee’s Convener.17 Sutter wanted to build an organization that
would promote C++ and be independent of (but supported by) the players in the C++ community. With their support, he was able to launch the Standard C++ Foundation18 and http://isocpp.org in late
2012.
In addition to serving as a single feed for all C++-related news, the website also became the home for the “C++ Super-FAQ.”19 The
Super-FAQ acquired its name because it is the merger of two of the largest FAQs in C++.
Bjarne Stroustrup, as the language’s creator, was the target of count‐ less, often repetitive questions, so he had created a large FAQ on his personal website.20
The moderators of the Usenet group comp.lang.c++ were also main‐ taining a FAQ21 for C++. In 1994, Addison-Wesley published this as
“C++ Faqs” by moderators Marshall Cline and Greg Lomow. In 1998, Cline and Lomow were joined by Mike Girou with the second edition,22 which covered the then recently released standard.
Both of these FAQs have been maintained online separately for years, but with the launch of http://isocpp.org, it was clearly time to merge them. The merged FAQ is in the form of a wiki so that the community can comment and make improvements.
Today isocpp.org is the home not only to the best source of news about the C++ community and the Super-FAQ, but also has a list of upcoming events, some “getting started” help for people new to C++, a list of free compilers,23 a list of local C++ user groups,24 a list
25Follow @isocpp https://twitter.com/isocpp
26https://isocpp.org/std
27https://isocpp.org/forums
28http://www.boost.org/doc/libs/
29http://www.boost.org/community/gsoc.html
30http://rrsd.com/blincubator.com/
31http://rrsd.com/blincubator.com/alphabetically/
of tweets,25 recent C++ questions from Stack Overflow, information
about the Standards Committee and the standards process, includ‐ ing statuses, upcoming meetings,26 and links for discussion forums
by working group.27
Boost: A Library and Organization
As described earlier, Boost was created to host free, open source, peer-reviewed libraries that may or may not be candidates for stand‐ ardization. Boost has grown to include over 125 libraries,28 is the
most used C++ library outside of the standard library, and it has been the single best source of libraries accepted into the standard since its inception in 1998.
The Boost libraries and boost.org have become the center of the Boost community, which is made up of the volunteers who have developed, documented, reviewed, maintained, and distributed the libraries.
Since 2005, Boost as an organization has regularly participated in the Google Summer of Code program, giving students an opportu‐ nity to learn cutting-edge C++ library development skills.29
Since 2006, Boost has gathered for an intimate, week-long annual conference, originally called BoostCon. More about this later. Recently, Robert Ramey, a Boost library author, has built the Boost Library Incubator30 to help C++ programmers produce
Boost-quality libraries. The incubator offers advice and support for authors and provides interested parties with the opportunity to examine code and documentation of candidate libraries and leave comments and reviews. There are currently over 20 libraries31 in the
incubator, all open to reviews and/or comments.
