C++29 Profiles
C++29 Profiles are opt-out memory safety. Built-in by default, designed for static analysis, and restricted code. A developer cannot write that which the project does not want.
What are Profiles?
Profiles are a new feature for C++29 to restrict the usage of functions and features in C++ in desirable manners. This becomes especially important for large code bases with rapid development progress for a few reasons:
- Reduced maintainer effort: Maintainers no longer have to scan your code while reviewing for calls to any “prohibited” functions. In fact, it is entirely possible that a function is not prohibited, but it is dangerous, so now maintainers don’t have to scan for its usage. They just need to disable it.
- Quantity of code: Within a volume of code, there is a high chance that one bug will be in a PR merged to main, and now, dangerous functions don’t have to be the reason.
- Quality: Imagine migrating an old codebase to follow better conventions, avoid manual allocations, etc. Usually, you would have to find usages of anything that you don’t want like manual memory allocations. It is not optional, it is not caught 99% of the time, it is forbidden. Build fails. Old styles have to grow with the code base!
Profiles For Memory & UB
Profiles will inevitably be powerful tools in addressing both memory safety and UB. For instance, you can prohibit all calls to malloc/new to completely avoid raw pointers. You can also remove free/delete to prevent someone from calling delete[] vec.data(). But that’s just the start of it. For any feature in C++, you control whether the developer has access to it. Simplified code bases, higher quality code, right from the get go.
Get Ekansh Jain’s stories in your inbox
Join Medium for free to get updates from this writer.
For UB, its a similar story. One common example of UB is uninitialized read: so, completely prohibit uninitialized variables. If the compiler can track that scenario of UB, you’ll be able to prevent it from happening with profiles. And the best part is, it’s completely compile-time. No runtime overhead for restricted functions.
On the other hand, you have runtime changes such as bounds checking by default, which has been introduced in C++26 with flags like -fhardened. These add minor runtime overhead, but for most applications, they are extremely helpful.
Don’t Like It? Remove It
With C++ profiles, you aren’t restricted. If something is default enabled, you don’t have to keep it. That runtime overhead is an option, not a mandate. You still have full control, but now you have the ability to give some of that control to the compiler. This way, C++ remains useful in performance-critical and safety-critical systems. Debug mode -> enable compile and runtime checks. Release mode -> enable compile time checks.
C++ has a future in the modern world. As safety grows more important, C++ is growing with it. It’s taken 15 years from C++11 to get here. But now, the language is about to be for everyone. Eventually, we might be able to opt-in to Rust-like safety. The horizon is endless, the difference is how much compilers can support.
