Modern C++ is not just C with a few additions. It offers facilities supporting a variety of application domains based on an efficient map to hardware and zero-overhead abstraction. In the context of embedded systems, I focus on effective use of hardware, resource management, reliability, and maintainability.
How do modern C++ measure up? How does the answers differ from different kinds of embedded systems? Programming a coffee machine is not the same as programming airplane controls and the two should not by conflated.
C++17 it is a remarkable collection of many many features both in the core language and the library, which you can use now in practice (VC++, gcc, clang).
It might look that it is easy to learn and to use. But beware, C++17 is a lot more complex than it looks like. There are nice hidden features, significant remarkable design issues, and important pitfalls (especially when combining new features).
This talks covers the most important of them.
Many people say that simple code is better code, but fewer put it into practice. In this talk I’ll spend a little time on why simpler is better, and why we resist simplicity.
Then I’ll provide some specific approaches that are likely to make your code simpler, and discuss what you need to know and do in order to consistently write simpler code and reap the benefits of that simplicity. Code samples will be in C++ and some material will be C++-specific.
Several groups work on specifying guidelines for making C++ software safe or secure, e.g., ISO JTC1-SC22-WG23, MISRA-C++, AUTOSAR, CERT. And there are also the C++ Core Guidelines proposed by Bjarne Stroustrup and Herb Sutter with other colleagues. Fortunately they inspire each other, but try to address different contexts.
Most of these Guidelines build around safe coding practices without losing C++'s efficiency, such as using const deliberately or minimize the use of raw pointers. Many of the guidelines provide hints for enforcing the guideline and some even require or imply effective static analysis tooling to make them useful.
Our institute has a long history of providing static analysis within an IDE and also suggesting transformation for improving code, such as, applying C++11's initializers, instead of uninitialized or old-fashioned initialized variable declarations. While already addressing some areas covered by the Core Guidelines, we recently targeted many more of those explicitly and provide corresponding static analysis and quick-fix refactoring support to adjust existing C++ code toward following the core guidelines.
This talk will introduce some of the C++ (Core) Guidelines and give some examples how you can modernize your code and improve its quality without losing performance through automated tooling built into Cevelop.
* What are the C++ Core Guidelines
** Philosophy and goals
** Relationship to C++ Safety Guidelines
** Areas covered
** Some safety-related Examples (Rule-of-Zero, RAII, Ownership-or-not?)
* Automatic "repair" of code
** const Correctness
** Pointers and arrays
* Future work
The audience will get an overview of the C++ Core Guidelines. Using practical code examples improvements through application of the guidelines is demonstrated. Tools will be shown, that aid in detection of guideline violation and automatic repair to guideline-conforming code. Attending developers will be enabled to apply the Core Guidelines in the future to create or refactor to safer and more maintainable C++ code.
This talk will cover some of the problems of lock-free, some of the reasons why these problems exist (what is the CPU doing), and, honestly, try to make you afraid to write lock free code, because it is too easy to get wrong.
As examples, parts of simple lock-free structures will be shown.