154. Embedded C++, Cpp2, September mailing

Media

Video

Podcast

Powered by RedCircle

CppCon keynote: Bjarne Stroustrup - C++ in constrained environments

  • Many systems have constraints that dominate the design – limited memory, limited CPU speed, extreme reliability requirements, limited latency, zero or limited downtime, long life (decades).
  • When teaching C++, these constraints are usually ignored.

Slide 6

  • There is no “silver bullet” – need to use several approaches in larger systems.
  • Targeting C++20 but usable from C++11.
  • Some people are stuck with C++98 (“That really shouldn’t happen these days”).

Slide 10

  • Language serves the programmer, not the other way around. Use as many new features as it is sensible for your environment.
  • Don’t optimise every line of code – measure, then tune.
  • C and C++ map directly to hardware, thanks to the genius of Dennis Ritchie.
  • C++ machine is itself an abstraction.
  • Make every construct checkable, so that rules are expressed in the code. Static checking can be difficult or impossible, run-time checking can be expensive.
  • Use immutable data – protect against data races.
  • Initialise your data.
  • Zero-overhead: leave no room below C++. Doesn’t mean “zero-cost”.
  • Resource management: RAII.
  • Move work from run time to compile time.
  • With modern C++ you can avoid falling back to C-style C++ and unsafe practices.
  • If you attempt to create a “safe” subset of C++ you end up having to write more code that has to be correct because you can’t use all the available language facilities. You can extend the language (STL, GSL) to avoid using unsafe techniques.

Slide 54

The error handling slide has a pretty terrifying picture, which checks out.

Don’t even dream of a single style of error handling for everyone supported by a single language construct.

  • Exceptions: in constructors, operators, callbacks
  • Return codes: in hard real-time code, when there are latency guarantees
  • Crash/terminate: universal, if you can use it
  • Exceptions are not zero-overhead, but neither are other error handling strategies. They can be zero-overhead on the happy path.
  • Don’t litter code with try/catch.
  • Don’t use exceptions for common failures that can be handled locally.

Slide 61

Slide 64

Slide 65

  • Common package mechanism and repository – was that considered not suitable to be part of the standard?
  • Static analysis with code transformation for code modernisation – that’s one of the goals of Carbon

Book: An Tour of C++, 3rd Ed.

C++2!! CppCon 2022: Herb Sutter - Can C++ be 10x Simpler and Safer?

This is Herb Sutter’s personal C++ evolution experiment. “The goal is to refresh C++ itself, not invent a new language”. The main idea:

Apply zero-overhead principle to backward compatibility: pay only if you use it.

A second syntax for C++, hmm… “If it doesn’t hurt a little, is it really C++?” He implemented his own major papers: metaclasses, value exceptions, parameter passing, and is/as pattern matching. I guess that’s one way of getting your paper into C++ (kind of).

Doesn’t this feel like TypeScript vs. JavaScript? Are we not going to end up with C++ being a ‘runtime’ language that nobody writes manually but instead use tools to generate it (see also: WASM)?

“What would Bjarne do?” (40 years ago)

  • Bjarne Stroustrup wrote cfront: C++ -> C
  • Herb Sutter wrote cppfront: C++2 -> C++

Let’s have a go at fragmenting C++!

Example:

In Cpp2:

  • Core Guidelines are the defaults
  • left-to-right declarations: name: type = value
  • no references (Herb really doesn’t like them, says they were introduced for parameter passing only)
  • implicit import std (modules-first design)
  • _ wildcard
  • optional return for single-expression functions
  • lambda is declared the same way as a function, but omits the name => short lambda syntax
  • order-independent syntax, no forward declarations
  • no preprocessor! (in pure mode)
  • automatically defined variables: local_foo := func(), whoa, he really used :=
  • universal function call syntax: vec.ssize() -> std::ssize(vec) (also helps IntelliSense)
  • all type casts done via as
  • union not supported
  • all variables are initialised before use; nullptr is not supported
  • no pointer arithmetic
  • delete and owning raw pointers are not supported
  • unary operators are suffixes: to get an address, follow the expression with &
  • contracts!!
  • parameter passing: out parameters (weren’t they discouraged? it looks like a regression from returning values…), also: copy, inout, move, and forward
    • in parameters are automatically const, and you don’t need to choose between passing by value or by reference (hi Carbon)
  • variable capture using $ for lambdas, post-conditions, and string interpolation

In the generated C++ code:

  • [[nodiscard]] is the default
  • auto-generated forward declarations
  • human-readable
  • uses namespace cpp2 :-)

Safety:

  • Cpp2 compiler implements optional bounds checking

Gradual improvement/migration:

  • C -> C++: .c -> .cpp -> OK (mostly)
  • JavaScript -> TypeScript: .js -> .ts -> OK
  • C++ -> C++2: .cpp -> .cpp2 -> OK (goal)

Plans:

Summary of problems solved by Cpp2:

Godbolt already supports cppfront.

Links:

September WG21 committee mailing

Papers

C++23 status

Steve Downey has a page with all the currently approved changes in C++23.

Twitter

Natalie Silvanovich writes:

Don’t let the perfect be the enemy of the good. Don’t let the good be the enemy of the okay. Don’t let the okay be the enemy of the kinda works maybe

Mention

C++ Club got mentioned on Reddit, woohoo!!