CppCon 2024

Efficient memory utilization is a critical aspect of software running in a multi-tenant environment, where resources are shared amongst different processes. Unlike languages with automatic memory management, C++ allows for manual memory management. Developers have control over when memory is allocated and released, which can lead to more efficient resource usage, but also can lead to mistakes causing problems in memory. 

You plugged new code in for a fancy feature and all functional tests were green! You clicked the deploy button, but 10 minutes later an alarm came -- machine memory usage had reached 90%! Things can get even more complicated when you work on a project with numerous contributors. How do you know which of the latest commits resulted in your process eating up all the memory of the OS and never releasing it back?

In this talk, I will try to put together some useful pieces from the real world in order to paint a comprehensive picture from the perspective of a novice C++ developer. By the end of the presentation, you'll have a basic understanding of C++ memory allocation, an awareness of potential memory issues, and the know-how to leverage tools for profiling and analyzing your C++ applications.

Software engineers have an astounding opportunity to benefit from programmable money: now we can program directly with value, introducing the objectivity, auditability, and neutrality of Open Source Code, instead of the opaqueness, ambiguities, biases, and other issues of conventional monetary processes.

Bitcoin is arguably the simplest of all cryptocurrencies, giving us a real opportunity to learn it at this conference. We’ll show examples of money programmability to demonstrate what is truly possible…

In this session, we will leverage our skill as programmers by describing Bitcoin's design as a Software Engineering project, using the white paper as the primary source material with the updates running today ("SegWit", "Taproot", Schnorr Signatures…), aiming to acquire an intuitive understanding of its programming language, Bitcoin Script. Wednesday, you’ll have the opportunity to see the details of Bitcoin Script at Kris Jusiak’s presentation, and on Thursday, we’ll discuss higher abstraction level protocols such as Lightning.

–

In Kris Jusiak’s presentation, Bitcoin Script: Implementation Details and Use Cases, scheduled for Wednesday, he will present the details which make programmable money possible.

In Eduardo Madrid’s presentation, Role Playing Bitcoin Protocols Including the Lightning Network, scheduled for Thursday, with just an intuitive understanding of Bitcoin Script he will describe the higher abstraction level protocols, such as the Lightning Network.

Join us on Friday for a panel in which Eduardo, Jon, and Kris will answer Bitcoin questions.

Most C++ developers are familiar with the type of errors that arise when a shared library is not found. If they are really unlucky, they are have also faced a situation where the the wrong version of a library is loaded. However, a lot of us resort to suboptimal solutions just to get going, without fully addressing the root causes.

A lot of the time, we focus on the “build” process, that is, producing our binaries and executables. But getting the runtime linker/loader to locate the right libraries (and the right versions!) has a unique set of challenges that  should not be overlooked - after all, running the executables is critical for running tests, continuous integration, and obviously end-users running our apps and services.

Managing dependencies continues to be one of the top frustrations of C++ developers as per the most recents ISO C++ Developer Surveys. When it comes to shared libraries - different applications try to locate them at different times: the build system (e.g. CMake or Autotools) when configuring the build, the linker at build time, and the dynamic linker/loader at runtime.

This talk will cover in detail the different scenarios in which shared libraries need to be located, and how this is handled by package managers, build systems, and the the OS level. Emphasis will be placed on familiarizing the developer with the relevant tooling across multiple platforms, as well as associated concepts (e.g. RPATHs).

An often overlooked aspect will also be covered: how to create a self-contained, relocatable bundle for our user-facing applications, decoupled from the developer environment, as opposed to “works on my machine”.

In game development the building and optimisation of data for the game is an important but resource intensive and time consuming process. In this talk I will describe techniques used to improve the performance and efficiency of a data build system that was developed as part of a AAA game project.

I will briefly describe the differences between how the game code and data building code operate, how those differences impact processing performance, how a profiler can be used to identify trouble spots, and describe techniques I used to improve multithreaded processing performance.

While this is coming from a game development perspective the techniques can be applied to any task based parallel data processing system.

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.