bjarnestroustrup / profiles Goto Github PK

Will profiles permit me to create a type on which it will be illegal to obtain a reference or pointer on? One way to ensure referential integrity is to prevent the taking of references and pointers to begin with.

This is useful for creating API handles, wrapper types, context managers, etc.

Such a type of course cannot exist easily on the heap. It would have to exist on the stack, as a global or possibly as a thread local object. It won't be possible to construct an array of such an object either.

All of this is fine b/c the intended use does not require heap based allocation. These objects move around stack frames threads etc. via copy constructor or assignment operator. Yes, the copy constructor should be allowed to accept an object of the same type via reference and the assignment operator should be allowed the same privilege. I hope that profiles make it possible to express such restrictions.

Unfortunately, shared pointers don't quite suit the use today because the language permits the taking of pointers and references to these which can lead to breaks in any intended referential integrity via shared pointer.

Hi,

I'm curious how the idea of "profiles" intersects with ideas about specifying or restricting "side effects" that code can use

For example, I might be trying to develop code that can be executed in parallel. To that end, I mark up an entry point function with some kind of annotation that restricts that function from reading or writing from global systems or through pointers. Additionally, I only want to be able to call functions that have the same restrictions (or if their implementation is visible, that verify as safe in the same way).

This seems pretty similar to the idea of annotating code such that it is "arithmetic safe" or "memory safe", just with different requirements of the code.

Is the idea here for users to be able to create their own "profiles" where they can mix and match turning on/off particular language features? Or are we only trying to chase profiles that enforce specific kinds of safety that we think can get standardized?

I was just thinking about this situation and I dont know if the Profiles idea already include something like the following, if so, just disregard this text.

It seems like many people always want some different feature, so if its possible to override some particular Profile rule it could create a way to people customize the Profiles to their will.

For example:
Considering a Profile just like a rule set, each rule could have a number.
So I could use something like that:
[[memory-safe-delete{3}]]
That would import the memory-safe profile to current file or project but ignore the profile rule number 3, for some compatibility necessity for example.
Some other code tag could exist to ignore half the rule set of some profile, and also should be possible to use more than one profile simultaneous and create an alias as a new Profile just for somebody's needs.
For example:
[[realtime{1-10}]] // That would import just rules from rule number 1 to rule number 10 from realtime profile.

using [[big-software]] = [[memoy-safe]] && [[realtime{1-10}]]

Tha would create a profile alias, or custom profile named big-software and it would consists of all rule set from memoy-safe profile plus realtime profile less rules from 1 to 10 from the realtime profile.

That would be good to keep the number of official Profiles low and at the same time allow people to customize the Profiles for their needs.

I think it would be better to have a low number of official profiles, like 10 or 15 than to have 300 of them if lots of people starts to want specifics profiles.

I am not sure if I am doing this right, but it would be great to upper bounds on execution of code paths. if there were some way to normalize impact of cache, assign time cost to acquiring and releasing resources, analyze the assembly and give upper bound on number of instructions in assembly for code for a given processor, and use cpu frequency as a input, it seems with some degree of fidelity you could statically give a time profile to code.

I'm not really experienced enough with C++ compiler architecture to have a thorough opinion on the design of this, but I think profiles should be something like composable rules or functions of the AST (?) that sufficiently knowledgeable users can create and compose. As I write this it strikes me that I'm just describing GCC/Clang plugins, but this should be portable.... pie-in-the-sky idea here but I hope it's worth mentioning!

This issue expands a question raised by @FalcoGer in #3 (comment)_

The question there, reworded, is this: say I write some library code and then annotate it as satisfying some profile. Now, does the local static analysis 100% prove that my library code actually satisfies all the requirements of said profile? What if some requirements are infeasible to statically analyze?

To me, this suggests that there are some requirements of a profile that both (a) are essential to that profile's guarantees, and (b) cannot yet be proved via static analysis.

If this is the case, it stands to reason that somehow or other, the library author must ensure the profile obeys these invalidatable aspects.

So, my questions I'm posing are:

• Is my reasoning correct, i.e. there are fundamental parts of profiles that cannot be analyzed and must therefore be handled by authors?
• How do we keep track of these requirements? Is there anything stronger than just guidelines?

This is more in line with C++0x concept design and other languages such as Swift, Rust, Haskell etc. Now that C++ has concepts, it would be nice to have a profile that performs early definition checking to function and class templates. This suggestion is inspired from a discussion on cppfront github here.
While I could not convince Herb to add early definition checking to cppfront, it was clear that the feature does have a place in today's C++.

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.

I suggest adding topics such as cpp, cplusplus, memory-safety in the About section