Experience converting a large mathematical software package written in C++ to C++20 modules

TL;DR

This paper explores converting a large C++ mathematical software package to C++20 modules, demonstrating feasibility, challenges, and impact on compile times through a case study of the deal.II library.

Contribution

It presents a practical approach for converting large C++ codebases to modules, including dual interfaces and analysis of technical and human challenges.

Findings

Conversion to modules reduces the library’s own compile time.

Downstream compile times show no clear trend post-conversion.

Feasibility of large-scale module adoption in mathematical software is demonstrated.

Abstract

Mathematical software has traditionally been built in the form of "packages" that build on each other. A substantial fraction of these packages is written in C++ and, as a consequence, the interface of a package is described in the form of header files that downstream packages and applications can then #include. C++ has inherited this approach towards exporting interfaces from C, but the approach is clunky, unreliable, and slow. As a consequence, C++20 has introduced a "module" system in which packages explicitly export declarations and code that compilers then store in machine-readable form and that downstream users can "import" -- a system in line with what many other programming languages have used for decades. Herein, I explore how one can convert large mathematical software packages written in C++ to this system, using the deal.II finite element library with its around 800,000 lines of code as an example. I describe an approach that allows providing both header-based and module-based interfaces from the same code base, discuss the challenges one encounters, and how modules actually work in practice in a variety of technical and human metrics. The results show that with a non-trivial, but also not prohibitive effort, the conversion to modules is possible, resulting in a reduction in compile time for the converted library itself; on the other hand, for downstream projects, compile times show no clear trend. I end with thoughts about long-term strategies for converting the entire ecosystem of mathematical software over the coming years or decades.