CppCon 2024

Learn what Return Value Optimization (RVO) is, and what you can do to ensure the compiler applies it on your C++ code! This talk is open to beginner, intermediate, and advanced C++ audiences, and will be especially valuable for engineers who work on large-scale and/or high performance codebases.

While this compiler optimization technique was first added into the C++ Standard way back in 1997, many of today’s engineers have forgotten to utilize it in their production-deployed code.

This talk will dive into different perspectives as to what RVO is, including how copy elision is defined in the C++ Standard, as well as an analysis of Assembly when RVO is enabled. We will cover the different types of RVO, compiler support for it, and guidelines to help programmers ensure that the compiler uses RVO on their code. These guidelines will tie into examples from real-world scenarios where engineers could have optimized their code to gain the time and space benefits that come with RVO. We will also showcase the performance improvements that come from employing this compiler optimization technique.

C++ is well known to be used, especially when efficiency matters and you want complete control of the resulting binary.

In this talk, you will learn about tricks the Standard Template Library uses to keep data storage size small. Are you familiar with Small String Optimization? Brace yourself for uncovering yet another ingenious strategy that might surprise you.

Everybody, including me, tells you how great `constexpr` is, but do you truly believe its potential? Embark on a journey with me as we delve into a compelling example demonstrating the transformative impact of constexpr, which enhances runtime performance while reducing memory overhead.

Furthermore, I'll unveil C++ Insights' capabilities and demonstrate how it can assist your approach to designing class data member layouts, ultimately optimizing the size of your data types.

Are you leveraging uniform initialization for your data types? Let's delve into the implications, especially when initialization necessitates a std::initializer_list. C++23 has an interesting change that might help you.

I am confident that this session will equip you with invaluable insights and practical techniques that can be readily applied to improve your codebase.

P.S: You miss lambdas from the description? Well, I promise I will show you a C++23 improvement to lambdas.

This is the story of a design collaboration between a member of our code governance team and a C++ developer leading the effort to update tools that generate C++ code from schema. Through a two year collaboration, we crafted guardrails to a complex system that allowed maximum flexibility to exist alongside common sense restrictions in a single system. We did so successfully thanks to the input and consensus of our huge C++ developer community.

Bloomberg's C++ code generator was created 18 years ago to simplify the task of writing services and code to call those services, freeing up engineers from writing boilerplate code and allowing them to concentrate on writing code that provides business value. The code generator is so popular that it is used beyond services, with hundreds of developers relying on it to also create C++ value semantic types. As a long-lived project, the generator has evolved over the years to support many scenarios and options. While this versatility has been hugely valuable, having so much additional flexibility also created a huge support surface for the tool owners and also burdened users with questions about which options are optimal for their use cases.

Two teams began exploring this problem separately. One focused on updating the code generator while the other looked into how the generator was being used across the company. Progress sped up appreciably when we realized we could combine our expertise in outreach and design. We began a focused conversation with the firm's broader engineering community, which led to key changes to the code generator, the creation of directed CMake modules, the introduction of new rules and validations, and the development of clearer documentation. We put an end to longstanding misunderstandings that had been causing users to make mistakes. Finally, we gave our engineers  a clear outreach path to request new features.


Key takeaways:
* Development and outreach teams working together can make targeted technical improvements to a C++ codebase, and to the developer experience.
* An outreach team can bring existing community relationships, as well as dedicated time, to research larger issues. This gives developers a chance to have a say in designing best practices, in addition to allowing infrastructure teams to make improvements, without bringing other important work to a stop.
* Creating a well-lit path for a tool's usage avoids pressure on developers to craft ad hoc solutions that are unintended and inadequately tested by the tool's creators and maintainers.
* People will do the right thing when everyone involved understands what the right thing should be. Your organization's codebase will benefit.

Achieving low latency in a trading system cannot be an afterthought; it must be an integral part of the design from the very beginning. While low latency programming is sometimes seen under the umbrella of "code optimization", the truth is that most of the work needed to achieve such latency is done upfront, at the design phase. How to translate our knowledge about the CPU and hardware into C++? How to use multiple CPU cores, handle concurrency issues and cost, and stay fast? 

In this talk, I will be sharing with you some industry insights on how to design from scratch a low latency trading system. I will be presenting building blocks that application developers can directly re-use when in their trading systems (or some other high performance, highly concurrent applications).

Additionally, we will delve into several algorithms and data structures commonly used in trading systems, and discuss how to optimize them using the latest features available in C++. This session aims to equip you with practical knowledge and techniques to enhance the performance of your systems and make informed decisions about the tools and technologies you choose to employ.

In this talk, we will delve into the limitations and challenges associated with using std::function, std::packaged_task, std::apply, and similar constructs in modern C++ development. Despite their utility, these constructs often introduce performance overheads by invoking copies and moves of captured member variables, leading to increased complexity and unexpected behavior. I will share practical examples and common pitfalls encountered in real-world applications. Finally, I will present an alternative approach I have developed to mitigate these issues, offering a more efficient and reliable solution for developers.

Session types are the next big thing that will ensure correctness of communication code, and thus make concurrent and distributed software more reliable and easier to construct... at least some people view them that way; although they might also be viewed as just a new weird thing from type theory realm ("functional programming stuff") devised by overly enthusiastic mathematicians, but which is too complicated and cumbersome to be of practical use. Whichever is your own point of view on the line between these two extremes, come to this journey through the first know implementation of session types in C++ if you want: to see the main idea of session types explained in practical programming terms, to understand how and when session types might be useful, or just to enjoy exploring the limits of C++.

The talk targets wider audience, and does not require any strong mathematical background. In the first part, it sets up a working definition of a type, discussing a few different perspectives, and gives a short overview of some models of asynchronous communication. In the second part, an implementation of session types is presented. The implementation is evaluated on an example, and some remaining challenges are described.