Wednesday, April 15, 2026

This page runs on coffee, please consider supporting it.

Tuesday, April 14, 2026

Monday, April 13, 2026

Sunday, April 12, 2026

Saturday, April 11, 2026

Preventing Integer Overflow in Physical ComputationsPreventing Integer Overflow in Physical Computations Integers overflow. That is not a controversial statement. What is 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 far more insidious problem is what happens when you don't 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. This article explains why that limitation is real, how other libraries have tried to work around it, and what mp-units provides to close the gap as tightly as the language allows.📝mp-units

Friday, April 10, 2026

Building C/C++ libraries for HarmonyOS with vcpkgWe're currently working on porting Qt to HarmonyOS . For our CI and developer machines, we need a number of third-party libraries built for HarmonyOS. Cross-compiling open-source C and C++ libraries for this platform has been a manual, error-prone process. Each library has its own build system, whether CMake, Autotools, or Meson. Each needs individual attention to produce correct binaries for the OHOS target. We have been maintaining a hand-written shell script that builds libraries one by one, with per-library workarounds for cross-compilation quirks. With our vcpkg fork, that script is now a single command.📝Qt Blog

Thursday, April 9, 2026

A brief history of C/C++ programming languagesInitially, we had languages like Fortran (1957), Pascal (1970), and C (1972). Fortran was designed for number crunching and scientific computing. Pascal was restrictive with respect to low-level access (it was deliberately “safe”, as meant for teaching structured programming). So C won out as a language that allowed low-level/unsafe programming (pointer arithmetic, direct memory access) … Continue reading A brief history of C/C++ programming languages📝Daniel Lemire's blog