How do units and linear algebra fit together? We get that question often. Two different questions hide inside it, and they have different solutions. The occasion for answering now is concrete: mp-units ships opt-in integrations that let mainstream linear algebra libraries (Eigen, GLM, and Blaze) act directly as the representation type of a quantity.
The Brno 2026 ISO C++ Committee meeting has just finished. It was the first meeting of the C++29 cycle, and quite a lot already landed in the working draft. Below are the highlights voted in during the closing plenary and an update on the quantities and units standardization effort.
Integers overflow. What is more surprising is how easily overflow can hide behind the abstraction of a units library.
Most developers immediately think of explicit or implicit scaling operations:
calling .in(unit) to convert a quantity, constructing a quantity from a different
unit, or assigning between quantities with different units. These are indeed
places where overflow can occur, and the library cannot prevent it at compile time
when the values are only known at runtime. But at least these operations are
visible in your code: you wrote the conversion, you asked for the scaling,
and you can reason about whether the multiplication or division might overflow
your integer type.
The harder problem is what happens when you do not ask for a conversion.
When you write 1 * m + 1 * ft, the library must automatically convert both
operands to a common unit before performing the addition. That conversion, which
you never explicitly requested, involves multiplication or division by
scaling factors. With integer representations, those scaling operations can
overflow silently, producing garbage results that propagate through your
calculations undetected.
No compile-time programming can prevent this. The values are only known at runtime. But very few libraries provide proper tools to detect it.
Physical units libraries are good at preventing dimensional errors and unit mismatches. They have not addressed a different category of correctness: domain constraints on quantity point values.
A latitude is not just a length divided by a radius. It is a value that lives in \([-90°, +90°]\), and anything outside that range is physically meaningless. An angle used in bearing navigation wraps cyclically around a circle, and treating it as an unbounded real number ignores a fundamental property of the domain. A clinical body-temperature sensor should reject a reading of \(44\ \mathrm{°C}\) at the API boundary rather than silently pass it downstream.
Type-level constraint enforcement for quantity points with this level of flexibility is a relatively unexplored area in mainstream physical units libraries. The approach described here is experimental, and there are certainly edge cases and design considerations we have not discovered yet.
It has been 1.5 years since the last major update on the ISO C++ standardization
progress here. It is not that I got lazy 
, but there was really not much
to share.
This time, things were different. We achieved a nearly unprecedented success. Probably not many people expected it, and I definitely did not! 🎉
Physical quantities and units libraries exist primarily to prevent errors at compile time. Some of them focus only on dimensional analysis and unit conversions. Others go further and prevent representation errors, semantic misuse of same-dimension quantities, and even errors in the mathematical structure of equations.
This article describes six safety levels that a quantities and units library can provide, with examples for each of them. Then it compares how leading C++ libraries and units libraries from other languages score across those levels, together with their performance and memory costs.
Two of the upper levels are the focus here. Quantity kind safety distinguishes dimensionally equivalent concepts such as work vs. torque, or Hz vs. Bq. Quantity safety enforces correct quantity hierarchies and scalar/vector/tensor mathematical rules. Both are well-established concepts in metrology and physics, and both remain widely overlooked in the C++ ecosystem. They go well beyond dimensional analysis and prevent subtle semantic errors that unit conversions alone cannot catch.
The mp-units documentation has two new sections: tutorials and hands-on workshops for learning type-safe physical quantities and units. The tutorials start at the first quantity you create, and the workshops go on to the more advanced patterns.
The mp-units documentation now has an automated systems reference generator. It extracts all quantities, units, dimensions, and their relationships directly from the library's C++ source code and documents them.