-
Who We Are
- What We Do
By Herb Sutter, Technical Fellow
Earlier this year, Citadel Securities hosted another C++ Meetup where I spoke about the sea change in progress toward memory/functional safeties and compile-time reflection, why it is game-changing, and why I think it will define a new era of C++ in the next decade.
The room was packed for the talk at my first NYC++ meetup, and it was great to see lots of friends there (including a bunch of WG21 members). From my talk to the Q&A to the reception that followed, the conversations were engaged, insightful and made me even more excited about how the developments in C++ are, and will continue to, create tons of interesting opportunities for engineers.
Sea Change: C++11 era -> C++26 era
In C++’s history so far, we’ve had only one major milestone that changed the way we write C++ code to the point that Bjarne Stroustrup said it “feels like a new language”: C++11, followed up by C++14/17/20/23.
C++11 changed how we write code to the extent that to this day you can look at 10 to 20 lines of code and immediately see whether it’s “C++11 era” or not. That’s because C++11 included many features we just use all the time: range-based for-each loops, lambda functions, standard smart pointers, { } initializer lists, and more. If you see any of those, you know the code is “modern C++.” We’ve built more great things on top of C++11 since then, including “big” features like concepts and coroutines and modules, but none of those have been as “major” in terms of affecting any random 10-20 lines of code so that they define a new style era; so far we’ve stayed in the era where “modern C++” still means “C++11 onward.”
That is going to start changing with C++26: In this era, having increasing memory/functional safety support and reflection support will change how we write code in a way we’ll start to notice in typical 10-20 LOC samples. So in the coming years I think we’re going to start calling code “modern C++” when it assumes more memory safety by default (such as the hardened standard library that was just adopted for C++26), uses more functional safety features like contract_assert and pre- and post-conditions that were also just adopted for C++26, and uses reflection-based techniques – all of those will frequently change how we write code, for the better. At the meetup, I also talked about how C++26’s std::execution (aka Sender/Receiver) is a game changer for both concurrency and parallelism, and why that’s a great surprise because those two requirements are very different.
How C++26 is Changing the Game: Applications and Opportunities
All these things in draft C++26 matter because they help us make our code better – more efficient, reliable and resilient. The improvements coming in C++ are directly applicable to our business at Citadel Securities, which is why we aren’t waiting for the ink to dry on the standard to adopt them and deploy them live. Here are two examples:
- std::execution: We’ve been using our own implementation of draft-C++26 std::execution for a while now in production to run all trading for an entire asset class and as the basis for our new underlying messaging infrastructure, written in-house by our experts who are ISO C++ committee members (and who continue to have active papers that are targeting C++26 to further improve the C++ core language to make implementations of std::execution easier to implement and use, based on our internal direct production experience). We’re continuing to actively push it further throughout our systems to be a unifying framework for all the heavily asynchronous work we do. Using std::execution does require a shift in perspective, but a positive one because it simplifies and unifies different asynchronous frameworks that we’ve built or acquired over the years.
- Memory safety and functional safety: We’re pushing fast and early adoption of the C++26 hardened standard library and contracts in our systems. Why? The work that we do as engineers at Citadel Securities powers critical systems that power trading globally – ensuring that we’re always active in market. Reliable and resilient systems aren’t just important, they are essential to our business – if we cannot reliably take the other side of a trade, we can’t operate our business. And system reliability doesn’t just matter to our business, it’s essential to keep markets working for everyone; for example, our automated equities platform trades over 23% of U.S. equities volume.1
By adopting a few well-chosen cutting-edge standard features early internally, we get to “live in the future” by using them right away even before they ship in the standard itself. That not only lets us get the technical benefits sooner, but it lets us build our individual expertise and experience with features that everyone will be using everywhere in the coming years.
What’s next in 2025
Meetups like NYC C++ flourish when companies engage to provide facilities and speakers. Citadel Securities was proud to sponsor the January meetup because we believe it is an investment in the community that benefits everyone – the attendees, and the sponsors. Everyone learns technically and gets connected professionally. Come see us at a future meetup! Some upcoming ones are below:
- In June, we’re planning to host the London C++ meetup with me and possibly another Citadel Securities expert as speakers. That will be right on the way to the next ISO C++ meeting in Sofia, Bulgaria, where a few days later we will finalize the feature set for C++26 and begin its final year of comment and fit-and-finish tuning.
- No promises yet, but it looks like there’s a good chance I’ll be in Asia Pacific sometime this year, possibly Hong Kong and/or Sydney. I’ve never given a conference or meetup talk in that region, and it would be a lot of fun! We’ll post more details as they firm up.
Interested in learning more about engineering roles or joining our team?
1.Measured based on publicly reported total transaction volume averaged over the past 12 months.
- What We Do
