Skip to content

Blog

Range-Validated Quantity Points

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.

Report from the Croydon 2026 ISO C++ Committee meeting

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! 🎉

Understanding Safety Levels in Physical Units Libraries

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.

  • in Features
  • 10 min read

New Systems Documentation Generator

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.

  • in Releases
  • 9 min read

mp-units 2.5.0 released

A new product version can be obtained from GitHub and Conan.

I initially had different plans for this release, but during development, it became clear that the new major feature I was working on was too large and would require breaking changes. This put me off track, and unfortunately, the mp-units development slowed down recently 😞

It also turned out that I got laid off, so now I depend solely on my C++ trainer's career to earn money to live. Fortunately, I delivered many in-house C++ trainings to my customers this year, and I hope this will also be the case in the upcoming 2026. I was also busy preparing for new talks and classes at this year's C++ conferences.

Having that much on my plate, a break from mp-units was needed to not burn out on the way. But hopefully I am back now, and I plan to continue working on long-awaited features.

That said, if you care about mp-units and would like to see it grow faster, please either contribute or consider sponsoring my work.

This release contains many small patches and improvements.

This post describes the most significant changes while a much longer list of the changes introduced by the new version can be found in our Release Notes.

Introducing Absolute Quantities

Until now, mp-units forced users to choose between points, which do not provide arithmetic, and deltas, which do not provide physical semantics. Neither of them covers the most common case, which is a non-negative absolute amount.

An absolute quantity represents an absolute amount of a physical property, measured from a true, physically meaningful zero. Examples include mass in kilograms, temperature in Kelvin, or length in meters (as a size, not a position). Such quantities live on a ratio scale and are anchored at a physically meaningful zero. Negative values are typically meaningless.

Absolute quantities stand in contrast to:

  • Affine points (e.g., \(20\ \mathrm{°C}\), \(100\ \mathrm{m}\ \mathrm{AMSL}\)) are values measured relative to an arbitrary or conventional origin.
  • Deltas (e.g., \(10\ \mathrm{K}\), \(–5\ \mathrm{kg}\)) are differences between two values.

Arithmetic on absolute quantities behaves like ordinary algebra: addition, subtraction, and scaling are well-defined and map naturally to physical reasoning. This article proposes making absolute quantities the default abstraction in mp-units V3, reflecting how scientists express equations in practice.

Note: Revised on May 12, 2026.

Bringing Quantity-Safety To The Next Level

All quantities and units libraries need to be unit-safe. Most of the libraries on the market do this correctly. Some of them are also dimension-safe, which adds another level of protection for their users.

mp-units is probably the only library on the market that additionally is quantity-safe. This gives a new quality and possibilities. I've described the major idea behind it, implementation details, and benefits to the users in the series of posts about the International System of Quantities.

However, this is only the beginning. We've always planned more and worked on the extensions in our free time. In this post, I will describe:

  • What a quantity character is?
  • The importance of using proper representation types for the quantities.
  • The power of providing character-specific operations for the quantities.
  • Discuss implementation challenges and possible solutions.