# What are new c++20 features that are relevant to scientific computation?

In my research department we plan a small seminar on the new c++20 language standard. There are exhaustive lists online presenting the new features of the language standard, some of which will be of interest to this community, some will be inconsequential.

I think I understand the advantages of:

• concepts (wiki) - clearer definition of (template-) interfaces within codebases and less cryptic errors in template resolution. We may explicitly state what a templated type should bring, reducing the need for duck-typing.
• keywords: [[likely]] and [[unlikely]] - tell the compiler how to do branch prediction!
• modules - collect headers in a module (fortran-style), (hopefully) helping in better include management and improved compilation times
• ...?

From the perspective of numerical computation, what are other c++20 features that are particularly useful?

• I am not sure I understand the format of this question. Currently, it combines a question and an answer in the same entity. Mar 16, 2020 at 18:27
• I tried reading through the new features of c++20, and with some of them, I understand how that might be useful for scientific computing. But for a lot of them I can't tell if they have any use for us. I guess other people might feel the same way so I started this question. Any answer in the form of: "The new feature X might improve Y in a numerical code" is what I am looking for. The Answers might provide a starting point for anyone who is updating his/her existing codebase. Mar 16, 2020 at 18:48
• Thank you for answering @user14717. Do you know if the access via the ranges library is performant? I like the idea of having better ways to work with array-of-structs, but I worry about the execution speed. Mar 17, 2020 at 10:26
• Great question; I think it depends on instruction generation. If I have time later I'll try to hack a mwe up on godbolt and see if the asm is any good. Mar 17, 2020 at 10:42
• Just checked: Currently ranges do not compile on clang trunk, so I guess we'll have to wait and see. Mar 17, 2020 at 12:02

• Feature test macros: HPC is generally stuck on old compilers or compilers with partially conformant implementations. This can help ease the pain of working on the custom architectures common in HPC. Example:
#ifdef __cpp_lib_source_location
#include <source_location>
#endif
...
#ifdef
auto sl = std::source_location();
std::cerr << "Error at line " <<  sl.line() << " of file " << sl.file_name() << "\n";
#else
std::cerr << "Error at line " << __LINE__ << " of file " << __FILE__ << "\n";
#endif

• While we're at it, I really like the source_location header; I've personally been reimplementing this same functionality over and over. In scientific computing I find it particularly relevant, since a properly written error message that can take you directly to the source line where the proper error occurred is invaluable.

• Math constants: No more 4*arctan(1) for pi; use std::numbers::pi;.

• Atomic floating point ops. Very useful for (say) multithreaded Monte-Carlo integration.

• I have not read the stop_token proposal, but near as I can tell it could be very useful. I once worked in a shop where the scicomp was all multithreaded and produced visualizations while the computation was ongoing, and what you learn when you can watch your simulation is that about 90% of the computations you start are for some reason or another bad; maybe the question is stupid or the parameters lead to unreasonable compute. So having a graceful way to cancel is very useful.

• The ranges library. Very excited to be able to use all the standard library algorithms on "arrays of structs" using projections.

• Another use for concepts is to prevent performance bugs. If I say an algorithm should work on a RandomAccessContainer and you pass in an std::list, pre-C++20 it should compile because std::list has a dereference operator []. But maybe it would turn an $$O(1)$$ algorithm into an $$O(n)$$, or an $$O(n)$$ to an $$O(n^2)$$.

• We also will be able to use Greek letters as identifiers. This might make mapping papers to code a bit easier.

• Thank you for the input! Mar 19, 2020 at 11:23

C++ is a general purpose programming language, and consequently the improvements that are made in successive standards are, by and large, not particularly geared towards scientific computing but to the general ease of programming complex software.

That said, there are a few features that I can see as quite useful in scientific software:

• For a variety of reasons, many scientific software packages are heavily templated. Concepts will make writing such packages easier, and easier to debug.

• std::span is a useful abstraction for software that allocates memory in large chunks and then interprets it in specific ways. This is certainly going to make interfaces with older software easier (think in particular with Fortran software).

I think that C++17 was actually the bigger step, in particular because of this:

• A lot of std functions in C++17 have gotten overloads where the first argument is an ExecutionPolicy. See, for example, std::foreach. This enables better use of today's multicore machines.

There are also post-C++20 improvements that will be interesting to use. These are currently part of the "Parallelism v2 Technical Specification". An example is the ability to queue tasks together using std::experimental::future::then(). This is going to make it substantially simpler to write task-graph-based codes.