Safety is one of the most frequently used and at the same time least precisely defined terms in today’s programming language debate. Hardly any concept is more often instrumentalized and less often examined in its full scope. In public discourse, safety is commonly reduced to memory safety, occasionally supplemented by the promise that entire classes of errors can be eliminated through language design. This reduction, however, fails to reflect the reality of complex software systems and overlooks the fact that safety is not a binary property but a multidimensional continuum.

C++ safety goes far beyond avoiding “use after free” errors

When real systems are considered, safety does not begin with the absence of “use after free” errors. It begins with a system’s ability to remain stable over time, to respond predictably under load, and to correctly implement all functional requirements. A safe system is one that answers within reasonable time bounds, degrades gracefully under failure instead of collapsing, maintains full control over its resources, and can be evolved over years or decades without invalidating tested and proven code bases. Safety therefore encompasses runtime guarantees, functional correctness, resource safety, data security, robustness, and long-term evolution. Any notion of safety that focuses solely on memory ignores the majority of actual risks.

C++ has always occupied a special position within this field of tension. The language grants developers extensive freedom and, with it, extensive responsibility. This freedom was never an accident but a deliberate architectural decision. C++ addresses experts and architects who are required to solve real and universal problems, problems that cannot be reduced to a single safety model. It is precisely this openness that makes C++ attractive for safety critical domains and, at the same time, vulnerable within a debate that prefers simple narratives.

What are the C++ profiles proposed by Bjarne Stroustrup?

Against this background, the Profiles proposed by Bjarne Stroustrup are of particular importance, even though they did not make it into C++26. Profiles are not an attempt to retroactively restrict or domesticate C++. They are an offer to make responsibility explicit. Profiles allow safety assumptions to be defined clearly and checked mechanically, without fragmenting the language into incompatible dialects. A profile does not describe what C++ is, but under which assumptions C++ is used in a specific context.

The key point is that profiles are multivalued. They represent different safety levels, usage scenarios, and qualification stages. A system can apply different profiles in different areas, consciously escalate or deescalate guarantees, and document these decisions transparently. Safety thus becomes gradual, context sensitive, and comprehensible. This approach reflects the reality of large systems far better than any binary classification.

What is wrong with Rust’s memory safety?

By contrast, Rust’s borrow model is often presented as a counterexample. Rust provides strong formal guarantees, but its safety model is monocausal. It largely equates safety with memory safety and enforces a specific view of ownership and lifetimes. This model is internally consistent, but it is not architecturally neutral. It is highly effective for certain classes of problems and becomes a structural obstacle for others. Above all, safety in Rust remains binary. Code is either safe or unsafe, with unsafe marking the end of a very specific guarantee rather than the end of risk itself.

This binary distinction ignores the fact that safety in real systems does not end where the borrow checker is satisfied. Logical errors, deadlocks, latency issues, protocol violations, or evolutionary breaks remain unaffected. Unsafe merely denotes the absence of one narrowly defined guarantee. Profiles, in contrast, would make different guarantee spaces explicit and therefore usable for tooling, static analysis, and certification processes.

Why is C++ safety better than you might think?

Another frequently overlooked aspect of safety is its temporal dimension. Software is not a static artifact but a long living system. Safety also means that code remains maintainable, analyzable, and adaptable over decades, without implicit assumptions breaking over time. C++ has a rare strength in this respect. The language evolves incrementally, does not invalidate existing abstractions, and allows new safety mechanisms to be introduced gradually. Many safety arguments in favor of other languages implicitly assume a greenfield context and ignore the reality of long-established systems.

There is also an economic dimension. Unsafe systems rarely arise from ignorance alone, but from time pressure and cost constraints. A language that treats safety as an all or nothing decision creates strong incentives to bypass safety mechanisms. Gradual safety, as enabled by profiles, allows security requirements to be increased incrementally and implemented in an economically viable way. This is not a secondary concern but a prerequisite for real world safety.

How is C++ safety better than Java’s approach?

The experience with Java illustrates the consequences of confusing prohibition with safety. Java removed many degrees of freedom and thereby narrowed the visible safety space, without automatically producing safe systems. Risks outside this space were not eliminated, only rendered invisible. The current political discussion around so called safe programming languages follows a similar pattern. Safety is interpreted as a reduction of freedom rather than as an increase in competence and awareness.

C++ needs to be more self confident in this debate. The language is not a relic of an unsafe past, but a tool for responsible experts. Safety does not arise from disempowerment, but from explicit models, qualification, tooling, and a problem awareness that extends beyond memory. Profiles would not represent a retreat from this philosophy, but its clarification.

Ultimately, better qualification is the only sustainable solution. Profiles can support this learning path by making safety assumptions explicit and allowing responsibility to be introduced gradually. They are not a substitute for expertise, but a means to make it effective. In a time dominated by simplified narratives, this may be the less convenient, but the more realistic answer to the question of safety in C++.

About the Author

Volker Hillmann is a mathematician and software architect from northern Germany with an interdisciplinary background that bridges formal science and applied computer science. His mathematics studies blend classical rigor with logical and cybernetic thinking, complemented by many years working with chaos theory, systems theory, and artificial intelligence. His work in computer science centers on databases, data security, and software architecture, with a consistently modern focus on C++.

He has programmed in Turbo C since 1988 and in Turbo C++ since 1991, and knows the evolution of the language and its tools firsthand. He has given numerous talks on C++ and software architecture and has been self employed since 2001. Since the mid 2000s he has also been an Embarcadero MVP, with a special commitment to advancing and applying C++Builder in practice.

His passion is modern C++. In his free live streams he focuses exclusively on current C++, independent of compiler, whether MSVC, GCC, or with the new release once again C++Builder. The topic is never a specific tool, it is always the language itself: C++ as an expression of architecture, precision, and thought.

He sees C++ not only as a tool but as a language of thought, a platform for structured, efficient, and safe design. In his current streams and articles, he evaluates and analyzes C++Builder 13 to show where modern C++ stands in practice, what is already possible, and which boundaries still need to be crossed. His topics range from RAII and move semantics to coroutines, ranges, and concepts, on to compile time metaprogramming and type safety. As a mathematician he thinks in systems and relations, in ranges, tuples, and mappings, and he applies that perspective consistently to software architecture. He argues for an understanding of C++ that unites responsibility, precision, and evolution, and shows that the language is neither outdated nor unsafe but the most precise and honest form of software design.