Achieving Safety in C++: Guidelines, Profiles, and Future Directions
0:00: Introduction to the talk on writing safe C++ and the speaker's definition of "safe". The focus will be on defining safety, current progress towards it, contemporary C++ practices using core guidelines, and profiles to guarantee safety.
0:09: Recent US government safety concerns and C/C++'s role. The presentation emphasizes that C++ remains relevant and actively used, highlighting the importance of its continued improvement.
0:02: The need to address safety to prevent real-world problems like faulty brakes.
0:02: A message to avoid "C/C++," promoting modern C++ practices. Someone else will dictate how it's done if they're not pro-active.
0:03: Complete type and resource safety has been a C++ goal from the start, though it is difficult.
0:03: C++ must remain versatile for diverse applications while improving safety, requiring judicious use of programming techniques and language enforcement.
0:05: Focus on type and resource safety is vital, ensuring objects are accessed by their defined type and properly managed.
0:06: The rules being put forward for improvement are deduced rather than invented. The enforcement rules suggested are mutually dependent. A framework is necessary.
0:06: C++ should support various uses without a one-size-fits-all approach. It must accommodate systems programming, hardware manipulation, and avoid outsourcing low-level tasks to C.
0:07: Stability over decades is crucial to maintain user trust that code written today will still run in the future.
0:10: Discusses logic errors, resource leaks, concurrency issues, memory corruption, type errors, and timing errors as aspects of safety beyond just type safety. Allocation predictability and termination errors are also considerations.
0:14: It must be clear what is being tried, and it's not possible to attempt everything everywhere.
0:14: There must be no confusion between security and type safety. Security is a system property involving many components beyond just the code's safety features.
0:16: Safe general-purpose languages need escape clauses for accessing hardware and improving efficiency.
0:17: Can't completely close all unsafe areas.
0:17: Safety is achieved where it matters most, with guarantees preferably by default. Highlighting this is no excuse to ignore safety issues.
0:18: Highlights static type safety and the importance of abstraction.
0:18: Simula's influence on C++ and the balance between progress, better hardware, and complexity management.
0:19: Evolution from crashing on basic errors to requiring explicit declarations shows progress, despite initial resistance to incompatibility.
0:21: The basic idea is to represent things in code and abstractions, simplifying it.
0:21: Abstractions are important, like the 'vector' and 'string' classes, and RAII (Resource Acquisition Is Initialization).
0:23: Focus on proper resource management with constructors and destructors for reliable resource release. Emphasizes avoiding resource leaks.
0:24: It was found that if people write complicated low-level staff it should not make it faster.
0:24: Object-oriented programming (OOP) emerged from Simula, enabling well-defined interfaces through classes and inheritance.
0:25: Evolution of the language with templates and Concepts has allowed compile time selection of implementations and precise interfaces. Use those consistently.
0:26: STL containers and smart pointers are important for safety. Emphasizes the importance of range checking.
0:27: The loops with spans and the C style loops are suspect. Spans know the size and make range checking better and we've known this for 20 years.
0:28: Illustrates using file handles appropriately in a class, with the destructor ensuring the file is closed. This emphasizes managing resources directly in the code.
0:28: The ideals for C++ include no implicit violations of the static type system.
0:29: The benefits come from using the language correctly, avoiding raw pointers, uninitialized variables, and other unsafe practices.
0:30: Emphasizing "good" C++ means using consistent features and avoiding low-level fiddling unless necessary. The speaker advocates a higher-level approach.
0:30: The community is urged to evolve towards provably safe coding to simplify static analysis, highlighting the limitations of just being careful.
0:31: Rules for safe use must be formalized, and methods for verification must be provided.
0:32: Highlights progress in areas like range checking and smart pointers but notes they haven't been integrated consistently. The core guidelines influence the goal of guaranteeing type and resource safety.
0:33: Focus on Static Analysis to help eliminate Potential Errors. Some code cannot be proven correct, and Global static analysis is unaffordable, needing rules to simplify.
0:34: Statically type safe checking can be checked at compile time.
0:34: We add no new language features. The use of all this be ISO standard C++.
0:34: Core guidelines influenced that they have to go further than the guidelines as I said, and being careful doesn't scale.
0:34: If I can understand what's going to happen, so can the optimizer.
0:34: Stresses Static Analysis, Libaries to support, that Static analysis can handle, and that are mutually reinforcing.
0:35: Explains that C++ core guidelines are not enough, and need guarantees because people make mistakes.
0:36: The "simple subsetting" strategy doesn't work, but first building better abstractions is important.
0:37: The aim is still guaranteed type and resource safe C++.
0:37: The language can be extended so as to make the code easier to manage and maintain.
0:37: By using abstractions (i.e., vectors, smart pointers, file handle classes) you can cut away the bad and dangerous parts of the code.
0:37: Stresses no new Language Features and to keep with Standard C++. The new code is meant to operate alongside existing code.
0:38: A number of recommendations for achieving a "safer" C++, such as: eliminating unitialized variables, detecting range errors, implementing "Smart Pointers" and other memory safety features, et cetera.
0:39: What's next, new or incremental changes? For a 10 million line program it would cost 1 billion dollars added cost.
0:42: Security and High Performance is usually needed for large, critical programs. Good and experienced programmers can maintain a system, but need good tooling to prevent errors.
0:44: Evolutionary changes, or a combination of them and C++ and what that means. Incremental and Evoluntionary are the way forward.
0:46: Gals law, a complex System that works is Invariably found to have evolved from a simple system that worked.
0:46: Guarantees safety with Standard C++ code are not enough.
0:47: Everything needs to be ISO C++ Standard. Type and source safety, and ownership have to constitute.
0:47: Offers Guarantees, which have to be supported. The Guarantee set are open. The assumption is that you are stated in code otherwise we don't know kind of analysis we applied for code.
0:51: There are Notions of Safety we need to meet: Logic Errors, Type Errors, Concurrency Errors, Memory Corruption, Timing Errors, Resource Leaks, Allocation Predictability, and Termination Errors.
0:51: States that C/C++ is not a style but a code.
0:52: Provides a list of code suggestions and good practices to meet.
0:54: Provides a Summary of what that should be in syntax to have the code analyzed, tested, and safe.
0:56: Provides what has happened thus far, but that we need to first get people who are not up to date with C++ be able to get up to date. This will create an easier process to get the features and code where it needs to be.
0:57: We need to first of all get people who are not up to date with C++ uh to become up to date it does not mean using every new feature.
0:57: This can't be done, but the code has to be written first before being analyzed so there is a level of trust that will be necessary.
0:57: He requests people to Refine profiles, best formalize specification, and if the library components could be simplified.
01:02: The speaker is setting up a GitHub repository to facilitate community involvement and collaboration on refining profiles and achieving safer C++ coding practices.
01:13: The speaker fields audience questions and provides a short synopsis for the questioner of what is being asked.