C++ creator rebuts White House warning, but there’s no smoke without fire :)

In a March 15 response to an inquiry from InfoWorld, Stroustrup pointed out strengths of C++. “I find it surprising that the writers of those government documents seem oblivious of the strengths of contemporary C++ and the efforts to provide strong safety guarantees,” Stroustrup said. 

And Stroustrup cited a fact about the origin of the issue :

There are two problems related to safety. Of the billions of lines of C++, few completely follow modern guidelines, and peoples’ notions of which aspects of safety are important differ.

This highlights a significant problem with C++. When any programming language permits the execution of potentially harmful actions, it shouldn’t come as a surprise that a considerable portion of developers may misuse it.

And when confronted about writing bad code, developers may offer various arguments to justify their actions, though these are often excuses rather than valid reasons:

  1. Tight Deadlines: “I had to rush because of tight deadlines. There wasn’t enough time to write clean code.”
  2. Legacy Code: “The existing codebase is messy and poorly structured. My changes just blend in with the existing mess.”
  3. Scope Creep: “The requirements kept changing throughout the project, making it difficult to maintain clean code.”
  4. Technological Constraints: “The technology stack we’re using isn’t suitable for writing clean code. We’re limited by what we have.”

So yes the developers have a responsibility to ensure they develop their code properly in C++. However, this kind of approach could be risky for the futur of C++. Just few years ago we have suprisingly assisted to the Nokia failure. Indeed, Nokia’s decline from being the world’s leading mobile phone manufacturer to struggling in the market is a story marked by several factors and strategic missteps. One of Nokia’s critical mistakes was its decision to stick with its Symbian operating system for too long. While Symbian was once a dominant platform, it struggled to compete with the user experience offered by iOS and Android.

In C++ we stick for too long with the current memory management mechanism and no radical solution is suggested, only few improvements that need to be applied by the developers.

C++ vs .Net startegy:

C# was developed in 2000 primarily for Windows machines. Miguel de Icaza created Mono to enable its use on Linux and Mac OSX. However, after over a decade of predominantly using the standard .Net framework on Windows, a significant issue arose regarding the language’s portability. To address this, Microsoft collaborated with Miguel to create .Net Core, a subset of .Net designed to function on other operating systems.

This is not a step by step solution to resolve the portability issue, but a radical one even if the legacy code is not compatible. at this time  Miguel de Icaza describes .NET Core as a “redesigned version of .NET that is based on the simplified version of the class libraries”,and Microsoft’s Immo Landwerth explained that .NET Core would be “the foundation of all future .NET platforms“.

And finally this solution worked perfetly and .Net core become widely used, and the big portability issue is resolved.

Ultimately, this solution proved highly effective, with .Net Core becoming widely adopted, successfully resolving the significant portability issue.

Why not take a similar approach with C++ to definitively address the safety concerns? Why not develop a safe subset of C++ and provide the option to work with this subset through the compiler?

clang –safe

Conclusion:

If C++ continues to allow developers to engage in unsafe memory practices, this significant safety concern will persist, potentially leading to other languages such as Rust or Go being preferred for new projects. Maybe, it’s time to think to a radical solution rather than step by step improvements. Certainly, experience has demonstrated that despite the availability of modern features in C++ aimed at addressing safety concerns for over a decade, the issue persists due to the language’s continued allowance of legacy bad practices.

What attempts have been made to bring memory safety to C++?

C++ is a powerful and widely used programming language known for its flexibility and performance. However, one of its historical drawbacks has been the lack of built-in memory safety features, which can lead to various types of memory-related bugs such as buffer overflows, dangling pointers, and memory leaks.

This is a known issue that has persisted for decades, and numerous attempts have been made to find a solution. Unfortunately, none have succeeded.

What has been done in the past to enhance memory safety within the language?

Continue reading “What attempts have been made to bring memory safety to C++?”

Make your C++ code more safer by enabling the native compiler Runtime Checks.

Runtime checks in C++ refer to mechanisms or tools used to detect errors, vulnerabilities, or unexpected behavior in a program while it is executing. These checks are performed dynamically during runtime rather than at compile-time and can help identify issues that may not be apparent during static analysis or code review.

Continue reading “Make your C++ code more safer by enabling the native compiler Runtime Checks.”

What about our emotional relationship with a specific programming language? C++ as example.

The emotional relationship between a developer and a programming language can be quite profound and personal, like to the relationship between a musician and his instrument. This relationship is shaped by various factors and experiences, leading to a complex mix of feelings and attachments.

Developers often feel a sense of comfort and familiarity with a programming language they have been using for a long time. They develop an intimate understanding of its syntax, semantics, and quirks, which can create a feeling of being “at home” when writing code. Emotional attachment to a programming language can fuel passion and motivation in developers. However, it can introduce some risks, like :

Continue reading “What about our emotional relationship with a specific programming language? C++ as example.”

Even the White House wants you to abandon C and C++, It’s time to focus on C++ safety and join the Bjarne initiative.

The C and C++ languages are no longer favored by the highest American authorities. Indeed, the White House wishes for developers to use memory-safe languages. In this report published on Monday, the Office of the National Cyber Director (ONCD) of the White House invites developers to reduce the risk of cyberattacks by using languages without memory vulnerabilities. IT companies “can prevent the introduction of multiple vulnerabilities into the digital ecosystem by adopting secure languages,” the presidency said in a statement. It refers to those that are protected against buffer overflow, out-of-bounds reads, and memory leaks.

Continue reading “Even the White House wants you to abandon C and C++, It’s time to focus on C++ safety and join the Bjarne initiative.”

Top 7 most used C++ idioms (Part1).

Idioms and design patterns are both common solutions to recurring problems in software development, but they differ in scope, granularity, and formality:

  1. Scope:
    • Idioms: Idioms are small, language-specific coding techniques or patterns that address specific programming challenges within a particular programming language. They often involve leveraging language features or conventions to achieve a desired outcome efficiently and effectively.
    • Design Patterns: Design patterns are higher-level, language-agnostic architectural solutions to common design problems in software engineering. They provide general reusable templates for solving design issues and promoting best practices in software design.
  2. Granularity:
    • Idioms: Idioms tend to be more granular and focused on specific coding constructs or techniques within a single programming language. They often involve manipulating language features or syntax to achieve particular goals.
    • Design Patterns: Design patterns are more comprehensive and deal with broader design concepts and relationships between components within a software system. They provide templates for organizing and structuring code at a higher level of abstraction.
  3. Formality:
    • Idioms: Idioms are typically informal and are commonly passed down through experience, code reviews, or programming literature within a specific programming community. They may not always have formal names or documentation.
    • Design Patterns: Design patterns are more formalized and well-documented solutions to common design problems. They often have recognized names, descriptions, and implementation guidelines outlined in literature such as the Gang of Four (GoF) book “Design Patterns: Elements of Reusable Object-Oriented Software.”
Continue reading “Top 7 most used C++ idioms (Part1).”

Are you curious to know where the move feature is used in your C++ projects, on your behalf?

Move semantics is a feature introduced in C++11 that allows more efficient transfer of resources (such as dynamic memory) from one object to another. It addresses the inefficiencies associated with deep copying objects, especially large ones, by allowing objects to “steal” the resources of other objects when possible, rather than duplicating them.

Before C++11, when you assigned one object to another, a copy constructor or assignment operator would be invoked, resulting in a deep copy of the object’s data. This process could be expensive, particularly for large objects or those containing dynamic memory allocations. This feature is particularly useful in scenarios where performance optimization is critical, such as in high-performance computing, game development, and resource-constrained environments.

Move semantics introduces the notion of “rvalue references” and a new concept called “move constructors” and “move assignment operators”.

Here’s how it works:

Continue reading “Are you curious to know where the move feature is used in your C++ projects, on your behalf?”

C++ is now a feature-rich language, Be aware of OverEngeniering

Being aware of overengineering is crucial when working with a feature-rich language like C++. Overengineering occurs when developers introduce overly complex or unnecessary solutions to a problem.

C++ developers could be attempted to use as possible the new features introduced by the new standards. which makes the code finally more complicated than it must be.

Here’s an example to show how C++ metaprogramming can be used to create a type-erased container with arithmetic operations that are evaluated at compile time. While this example show the power and flexibility of C++ metaprogramming techniques. it might seem complicated due to the use of templates, concepts and constexpr functions:

Continue reading “C++ is now a feature-rich language, Be aware of OverEngeniering”

Proposal for the next C++ standards

Modern C++ refers to the evolution of the C++ programming language beyond its original design principles, incorporating newer features, idioms, and best practices that have emerged since the language’s inception.

C++ is standardized by the International Organization for Standardization (ISO). C++ standards are typically released every few years, bringing new features and improvements to the language.

Continue reading “Proposal for the next C++ standards”