Why 4 Bloomberg engineers wrote another C++ book

Cover of "Embracing Modern C++ Safely"

Last month, Embracing Modern C++ Safely was released into the world. The book was written by John Lakos and Vittorio Romeo, with assistance from Rostislav Khlebnikov and Alisdair Meredith. All four are Bloomberg software engineers who have spent their careers applying C++ to solve some of the company’s biggest technical challenges.

But why do we need yet another C++ book? After all, one of the book’s principal authors, John Lakos, has already written two. And why now? Why Bloomberg? Who is this for? But first, why modern C++?

The revolution

In 1998, the International Organization for Standardization (ISO) published the first global standard for C++. The language was already being used on nearly every computer on the planet, but this release was a major milestone for C++, establishing many useful features. The next decade brought only incremental changes, minor tweaks, and bug fixes; the Standards Committee did not have a formal roadmap for evolving the language. Eventually, the volume of useful features developed by the C++ community at large became too large to ignore, and computing power had increased to accommodate more demanding use cases. In 2011, a watershed new standard was finally released, adding many new features and significantly enlarging the Standard Library. What’s more, the Committee, recognizing the need for more regular updates, committed to a schedule for standardizing new features every three years.

The changes and additions in C++11 were so sweeping that they came to be seen not as an evolution but a revolution in what the language could do. What came after can be thought of as modern C++. These features are the focus of this book.

Many of these newer features offer opportunities to improve performance, expressiveness, or maintainability, yet they are of questionable safety in some sense. As the language grew in complexity, engineers could more easily head down a path that could yield potentially risky results for their employers. When dealing with large enterprise applications, the stakes are high, so these modern C++ features must be applied with caution.

Embracing Modern C++ Safely arose out of a paper co-written in 2017 (and revised in 2018) by Rostislav Khlebnikov, who leads the BDE Solutions team at Bloomberg, and the aforementioned Lakos, senior architect at Bloomberg. Among Lakos’ many roles, he serves as a mentor for C++ development worldwide and is an active voting member of the C++ Standards Committee’s Evolution Working Group. The paper concisely describes the new features in C++11. But at only 9 pages (in 11-point font), the paper could hardly do justice to the vast swath of changes comprising the release. Across its 1,376 pages, Embracing Modern C++ Safely expands greatly on the paper. The authors limited the book to features with which they have accumulated more than five years of experience. The current edition is an authoritative summary of C++11 and C++14 features, and future editions are planned to cover C++17 and C++20.

John Lakos
John Lakos

A veteran C++ programmer, Lakos provided leadership and stylistic vision for the book, while also serving as a “guinea pig” for the material. Romeo and numerous other contributors wrote the initial drafts about each feature, and Lakos used that material to learn more about the language’s newer features with which he was less intimately familiar. Khlebnikov led the revision process, helping to distill reviewers’ insights into clarified explanations of the different features.

Another contributing author is Alisdair Meredith, a senior software engineer in Bloomberg’s BDE team, who has served on the C++ Standards Committee since the inception of C++11. Meredith provided some historical perspective, drawing on his close experience with the Standards Committee’s decision-making process to explain precisely why and how the features work as they do.

“All the detail was captured feature by feature. There’s so much we uncovered on things that we thought were well understood,” says Meredith. “We had many different people contributing to these chapters, and I don’t think there was any single feature where I didn’t learn something new, and I’ve been doing some of these things for 15 years or more. The huge value for me is having it all in one place.”

Alisdair Meredith
Alisdair Meredith

Why Bloomberg invested its resources in this book

“At Bloomberg, we have a unique situation,” says Vittorio Romeo, the book’s other principal author. “We have pretty much every version of C++ co-existing because of our legacy platforms. So when you join Bloomberg, you’ll see code that was written decades ago, and you’ll see bleeding-edge C++ code that was written yesterday. Programmers need to understand why legacy code was written the way it was, while also learning how they can make improvements during migrations once we have access to new features. So this book could have been written only at Bloomberg.”

Romeo is a senior software engineer at Bloomberg who specializes in programming with modern C++. He spends a lot of time teaching Bloomberg engineers of all skill levels the risks and advantages of the language’s latest features. His experience as a trainer gave him years of student feedback upon which to draw and an intuitive understanding of how best to explain often complex concepts.

“Unlike many other C++ books, we are really trying to capture the experience that you can get only by using these features in practice on a large scale,” says Romeo. “Some of the issues described in the book become apparent only when you are working in a large organization. There are many great books on sale from many great authors, but many of them seem to stop at a superficial level, especially when teaching new language features. You regularly get a bunch of new C++ books a few months after each standard release, and they tell you what’s new and explain the syntax and how you can use new features in your toy project. But it’s impossible for a book to contain any real-world experience when it’s published only a few months after the release.”

Vittorio Romeo
Vittorio Romeo

“One of the interesting things about Bloomberg’s engineering ecosystem is that there are hundreds, if not thousands, of small, disparate teams that are cooperating and working together, but there’s no central authority that dictates absolute policy as to how code is written across the company,” says Meredith. “Each of these teams is working together with a common vision, but we all have our own separate guidelines. If you want to be successful in this kind of environment, you have to be prepared to constantly be learning. This book is a great resource to educate all the engineering teams across the company in a consistent manner so we can move forward in unison.”

Lakos adds that Bloomberg is an ideal corporate sponsor for the book: “We’re one of the few enduring tech companies that is big enough to absorb the massive time investment required to produce the book, since we will also reap its benefits for years to come.”

“This [book] required a lot of research, a lot of money, a lot of buy-in, and a lot of risk, and that’s probably why no one has written a book like this before,” says Romeo.

The authors acknowledge a crucial reliance on feedback from a wide network of engineers from both inside and outside Bloomberg. Notably, Joshua Berne, Nina Ranns, Pablo Halpern, and Dr. Andrei Alexandrescu helped gather, revise, and refine the content as the authors worked through each feature.

Who is this book for?

Embracing Modern C++ Safely serves as a teaching tool and reference guide for programmers working in large-scale enterprise environments, many of whom were trained on classic (as opposed to modern) C++. This book will enable them to take advantage of proven modern language features, while avoiding common pitfalls. The first chapter describes safe features that come with minimal risk, while the second and third deal with riskier conditionally safe features and unsafe features, which the authors urge readers not to mess around with until they really know what they’re doing. Knowing which features are better left on the shelf can be a value all its own.

“You can have a valuable experience reading the book thoroughly from cover to cover, but you don’t need to,” says Meredith. “You’ll still want to revisit it as a reference manual, even if you’re familiar with the material. I came to this project extremely familiar with the material, or so I thought. I was meant to be the technical expert, but it turns out I had a lot to learn.”

Although the book is relevant to programmers at all levels of an organization, Lakos believes it will be especially valuable to senior technical managers at large enterprises. Many of these leaders must make critically important decisions, but they might not be familiar with these modern C++ features. This book can guide such decision-makers regarding whether the use of a given feature requires extensive training for it to be maintainable. In some cases, these technical leaders may direct that certain features be used sparingly and for only good, objectively verifiable reasons. The book provides several examples of both safe and questionable uses, thereby helping leaders proactively prevent expensive blunders by their teams.

“You have folks who were excellent C++ programmers in their day and are familiar with sound design in C++03, who were promoted to team leads and managers and ultimately senior managers,” says Lakos. “There’s no way in the world they can keep up with the evolution of the language. Nonetheless, they have to make company-wide decisions. There are a lot of people out there who are still programming in C++03. This is a book that says without pretense, ‘If you’re a good developer who understands C++03, this is the overlay that allows you to incorporate individual features with random access.’”

The book will also help guide firms as they allocate upskilling dollars. The book makes it clear which features are most accessible, useful, and safe for implementation — and therefore deserving of a company’s investment to teach — and which ones should be relegated for extremely niche use cases and restricted to advanced practitioners.

“As a trainer, I am excited about using the book as a reference to build courses,” says Romeo, who will be using Embracing Modern C++ Safely to derive development and training material for Bloomberg’s engineers in 2022 and beyond. “That will be super useful because I don’t have to think about doing all the research. It’s already all there. Trainers will be able to tailor the book to their own company and will get lots of value from it.”

The book also helps facilitate knowledge sharing between seasoned programmers with institutional knowledge and eager programmers who want to implement shiny new features.

“Experienced talent needs to learn from budding C++ programmers to progress in the fresh features,” says Lakos. “But these ambitious professionals also need to hear from veteran programmers that there are things that you learn only through bitter experience.” Embracing Modern C++ Safely helps convey both lessons to both groups.

Safety first

Collectively, the authors represent many decades of experience with C++, specifically within the context of large enterprise applications. They are quick to admit they’ve made expensive mistakes over the years and have learned from both their and others’ mistakes, and their goal is to prevent needless wastes of productive developer time and company money.

“We want to convey information that you would otherwise need years of experience to actually gain,” says Romeo. “Reading this book will immediately make you a much better software engineer, without having to go through years of pain. It will enable you to understand potential problems without risking your own skin.”

“This book was written with the enterprise in mind, not just the enthusiastic developer who wants to try out new features,” says Lakos. “When doing large-scale development, an engineer can inadvertently torpedo an entire organization while trying out fun new features.”

“One of the things we teach in the book is that you shouldn’t take things at face value,” says Romeo. “Even if a feature seems pretty nice, and you start using it everywhere because it seems innocent in isolation, then when you get to the point of having multiple engineers or a larger scale, something that’s seemingly inconsequential can become a pain. This is especially true if there is a long chain of dependencies between you and the other engineers, because you might need those people to change something so you can get your job done.”

“The pitfalls we chose to discuss in the book are not readily accessible,” says Khlebnikov. “At best, they are distributed throughout a vast sea of information. Someone mentions one in a conference talk. Another is written about in a book. It’s all scattered, and there wasn’t an authoritative source that collected them all in one place.”

Rostislav Khlebnikov
Rostislav Khlebnikov

“The ‘safe’ features in Chapter One are probably worth everybody’s time,” says Lakos. “It’s not a significant investment. The ‘conditionally safe’ features in Chapter Two are another story; some of them are a real investment in effort and time. The ‘unsafe’ features in Chapter Three are there to scare you. You’re going to spend a tremendous amount of time learning why you shouldn’t be using a given feature!”

Meredith adds, “For Chapter Two features, you want to read the ‘Potential Pitfalls’ section because these are features you’re most likely to use. For Chapter Three features, start with the use cases. If your specific use case is not there, you probably shouldn’t be thinking about using the feature.”

Despite these warnings, Embracing Modern C++ Safely is not prescriptive.

“The book doesn’t prescribe any solutions,” says Khlebnikov. “That’s because those solutions depend on your respective organization. There are coding guidelines that have to be developed, and they will be different for different companies.”

“Words like ‘should’ are banned,” echoes Lakos. “We say, ‘If you do X, then Y will happen. When we call an idea ‘bad’ in the book, it’s a really bad idea. And we did our best to explain all the technical reasons why it’s objectively wrong, not just suboptimal.”