profiles-wishlist

[PooyaEimandar]

Hello @BjarneStroustrup

First of all, thank you for your groundbreaking contributions to the development of the C++ programming language. It is truly appreciated. Based on your talk, I assume that in the future, we will have something similar to Rust with the Clippy feature for C++, but this time, these profiles will have specific target use cases in various fields of the industry. So to answer your questions:

• Set of profiles – what profiles do we need? which should be part of an initial set? Which should be standardized? Which should be defined as unions of other profiles?

My proposal is

1 - CppCore: This profile checks for adherence to the C++ Core Guidelines. 2 - Deprecated: This profile prevents the use of deprecated code and libraries. 4- Style: This profile checks for naming conventions and code style guidelines based on clang-format (e.g Google, LLVM and etc.) 4- Memory: This profile checks for:

• Memory usage analysis
• Compile-time allocation and deallocation tracking
• Compile time Tracing object reference chains
• Compile-time and run-time memory leak detection
• Memory usage patterns

5- Embedded: Based on the Memory profile, this profile is customized for resource-constrained embedded systems (e.g., NO_STD_LIB). 6- Performance: this profile is tuned for performance and fearless parallelism. 7- Realtime: Based on Performance profile, this profile tuned for real time applications that require high computing capabilities from both the CPU and GPU. 8- Safety-Critical: Based on the Embedded and Realtime profiles, this profile is optimized for critical systems.

• How do we specify a profile? As a set of guarantees; not, simply as a set of detailed rules. We need examples of profiles: both the set of guarantees and an initial set of detailed rules for delivering those guarantees.

We should start by establishing a set of guarantees and then provide specific details for each category. The initial set may encompass, but is not limited to, three key areas: Performance, Safety and Behavioral. Then ask what type of behavioral, safety or performance this profile aims to achieve. (e.g sometimes, we use unsafe code for performance, and other times, we need to add many verification and assembly codes to keep things safe).

• The Core Guidelines has been our initial proving ground for rules for good (and often safe C++ code). We need more rules and rules taking advantage of C++20 and C++23. Individual suggestions can be made directly on the CG GitHub, but larger sets of suggestions and suggestions directly related to profiles belong here.

Agreed, I'm pretty sure C++20 Concepts is a valuable asset!

• Comments/analysis on how various compilers could accommodate profiles.

The biggest problem we currently face is the divergence of compiler strategies. Each one has taken a different approach for memory safety. In my opinion, the only way to overcome this situation is to bring the static analysis, Lifetime annotations for C++, Microsoft GSL and others as the part of the language itself.

• Comments/analysis on how various static analyzers could accommodate profiles.

We encounter a similar issue in the field of static analysis. For instance, we have several static analyzers, but the majority of them are not cross-platform. The Clang Static Analyzer represents our best chance.

• Names of individuals and groups working on profiles and similar projects.

I would love to collaborate in this endeavor, but apart from the ISO members I don't know of any individuals or groups at the moment.

[Shadoware]

I suggest all the community to focus on memory safe profile as the high priority works! I think everybody knows how many circles and institutions are pressing for this feature and even suggestion changing the programming languages to memory safety ones. So I think this should the top priority. After that the community can get whatever they want without hurry.

[BjarneStroustrup]

I wrote a note about how to start for the standards committee. It will become complete and available in a couple of weeks. It points to memory safety, and the need to be precise about how we use that term.

[BjarneStroustrup]

[PooyaEimandar]: I'm working on creating a framework for collaboration.

[FalcoGer]

So a profile is just a static analyzer check, like clang-tidy modules? I'm a little confused by the whole concept. I'm no expert by a long shot and respect him greatly, but I feel like Bjarne just throws this term into the room and expects everyone to know what he's talking about. Or maybe I didn't catch the part where he explains it in more detail.

A profile to me conjures an image of a crossection, or an assortment of traits for a thing compiled into a single document, like an online profile. Or maybe some sort of performance analysis.

I watched the talk "Delivering Safe C++ - Bjarne Stroustrup - CppCon 2023" and I feel like whatever can be done with static analysis and potentially more language features such as annotiations and library features, such as gsl::not_null (should be part of the STL, IMO), doesn't require inventing a new thing.

As for memory safety, simply flagging every naked new or delete should get rid of 90% of the problems. Range constraints are already flagged by things such as modernize-avoid-c-arrays, suggesting std::array instead. Indexing pointers is already flagged by cppcoreguidelines-pro-bounds-constant-array-index or cppcoreguidelines-pro-bounds-pointer-arithmetic.

So what is this whole profile thing about? You can never make a language 100% safe, any language, at least not a general one that can solve any problem. Is this what profiles are about? Constructing an area of code that is guaranteed to be safe, and then allowing and explicitly flagging unsafe code in areas specially created for dangerous things, like rust does?

Let's take dangling references/pointers. A vector's element can be pointed to, and when a vector's function like push_back is called, it might reallocate, invalidating all references into it.

A profile is then some construct that keeps track of whether such a function has been called between making that reference and calling such a function that invalidates them. How can such a thing even be done outside of runtime? It seems impossible. What seems feasible is to either disallow such functions that invalidate entirely, or to disallow creating references into containers such as vectors that can be invalidated, the latter making more sense to me and what I generally do. A reference might be safe if it doesn't leave the scope and it can be guaranteed by some form of static analysis that no potentially invalidating function is called between it's creation and it's use.

But how do you implement this generally, and not just for standard containers? Is it even possible?

[jee7s]

The item 8 above is particularly important to address for safety critical code. Without a MISRA-like concept in C++ profiles, it will be difficult to gain broader adoption in these areas of criticality. This has been discussed by others at various conferences including cppcon, but I wanted to call it out as an important area for embedded, auto, aviation, industrial, and robotics.