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

2025-06-26

AI Summary

To address compilation redundancy, fragile dependencies, and inefficient builds caused by traditional C++ header-based interfaces in large-scale mathematical software, this paper proposes the first progressive C++20 module migration framework tailored for ultra-large scientific computing libraries—exemplified by deal.II (800K lines of code). Methodologically, we design a dual-mode (header/module) coexistence interface, customize the CMake build system, and develop a systematic compilation performance analysis toolchain. Our key contributions are: (1) a fine-grained, backward-compatible module partitioning strategy; (2) empirical validation that modularization reduces the library’s own compilation time by 37% on average, while downstream project compilation overhead shows no statistically significant change; and (3) the first established technical pathway and collaborative paradigm for scaling C++ modules across the scientific computing ecosystem.

Technology Category

• Computer Vision: Other Foundations of Computer Vision
• Reasoning under Uncertainty: Probabilistic Programming
• Machine Learning: Matrix & Tensor Methods

Application Category

• Systems and Infrastructure for Web, Mobile and WoT: Experiences and lessons learnt from Web-based algorithms and system deployments
• Graph Algorithms and Modeling for the Web: Efficient manipulation of static and dynamic Web-related graphs
• User Modeling, Personalization and Recommendation: Practical large-scale studies of user experience

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.

Problem

• Converting large C++ math software to C++20 modules
• Addressing clunky header-file interfaces in C++
• Ensuring compatibility between header and module systems

Innovation

• Convert C++ packages to C++20 module system
• Dual header and module-based interface approach
• Reduce compile time for converted library