Welcome to SwedenCpp

Latest blogs, videos, podcasts and releases in one stream

Friday, July 24, 2026

Introducing Logarithmic Quantities and UnitsIntroducing Logarithmic Quantities and Units Decibels are everywhere in engineering. Signal levels in dBm , sound pressure in dB SPL , voltage gain in dB , filter slopes in dB/octave . The neper, pH, and stellar magnitude are the same idea wearing different clothes. Yet, to the best of our knowledge, no general-purpose units library models logarithmic quantities correctly. Most do not model them at all. The few that do treat a decibel as a non-linear scale or an offset unit, and that choice gets the arithmetic wrong in ways that compile silently. This article is a request for feedback . We believe we have a correct design, derived from the same affine-space model we introduced for absolute quantities . It also aims to stay consistent with the ISO/IEC 80000 standards: especially IEC 80000-15:2026, Logarithmic quantities and their units , which consolidates the logarithmic-quantity rules once held in ISO 80000-1:2009 (Annex C); together with ISO 80000-2 (the logarithm functions lb , ln , lg ), ISO 80000-8 (acoustics), and IEC 80000-13 (information theory). We have read those against this design, cite them throughout, and call out the one place we knowingly diverge from them ( Open Question 5 ). This post describes the design in full, from the quantity spec to the named units, the arithmetic, the conversions, and every domain we surveyed (audio, RF, acoustics, chemistry, astronomy, music, information theory). Then it lays out the open questions , each with every alternative we considered and our current preference. Before we implement any of this in mp-units , we want the people who use these quantities daily to tell us where we are wrong.📝mp-units

If this page is useful, please consider donating a coffee

Thursday, July 23, 2026

The PImpl idiom and the C++26 std::indirect typePImpl (which stands for Pointer to implementation) is a programming tehnicque to remove implementation details from a class by placing them in a separate class that is accessed through an opaque pointer. Its purpose is to separate interfaces and implementations and minimize compile-time dependencies. In this article, we’ll at how the PImpl idiom is typically ... Read more The post The PImpl idiom and the C++26 std::indirect type first appeared on Marius Bancila's Blog .📝Marius Bancila's Blog

Wednesday, July 22, 2026

From Institutions to Individuals: the White House Report on Revitalizing U.S. Scientific LeadershipIn 1945, Vannevar Bush published a report entitled Science: The Endless Frontier. His thesis was that prosperity follows from basic research. The report was highly influential in the United States and elsewhere. It led to the creation of an entirely new government bureaucracy. With this report, Bush popularized the linear model of innovation: innovation (such … Continue reading From Institutions to Individuals: the White House Report on Revitalizing U.S. Scientific Leadership📝Daniel Lemire's blog

Tuesday, July 21, 2026

Prefactoring: Clear the Way for Your New Feature@media only screen and (max-width: 600px) { .body { overflow-x: auto; } .post-content table, .post-content td { width: auto !important; white-space: nowrap; } } This article was adapted from a Google Tech on the Toilet (TotT) episode. You can download a printer-friendly version of this TotT episode and post it in your office. By Rahul Singal “First make the change easy, then make the easy change.” - paraphrased from Kent Beck You're working on a new feature, but the existing code wasn't written with future changes in mind. Trying to force the feature in directly gets complicated fast. One change leads to another, and before you know it you're already a few files deep fixing things you never planned to touch. Prefactoring (short for "preparatory refactoring") is the practice of reworking existing code to make it more suitable for an upcoming change before you actually implement the new functionality. Instead of cleaning up code as an afterthought or trying to force a new feature into an incompatible structure, you restructure the codebase first. Prefactoring helps you: Easily implement new features: Restructuring the codebase first ensures your new feature fits naturally into the code. Speed up reviews: It's easier to review the refactoring and the feature in separate changes. Avoid bugs: Isolating cleanups from functional logic can help prevent bugs . Roll back safely: If you need to roll back, it is much easier to revert small, focused changes. Here is a simplified example of a prefactoring change: Change 1 (Prefactoring) Extract display name helper to remove duplication. Change 2 (Feature) Add middle name support. + def get_display_name(user): + return f"{user.first_name}” {user.last_name} # Profile page - display_name = f"{user.first_name} {user.last_name}" + display_name = get_display_name(user) # Email template - greeting = f"Hi {user.first_name} {user.last_name}, " + greeting = f"Hi {get_display_name(user)}," def get_display_name(user): - return f"{user.first_name} {user.last_name}” + return f"{user.first_name} {user.middle_name} {user.last_name}" You can prefactor a change that is already in review too! If your reviewer suggests a related cleanup during review, you can also extract it into a new base change to keep your current change focused on the feature. Note that not every cleanup needs to be prefactoring: you can do the cleanup in a follow up change if the cleanup doesn’t block your feature, or even in the same change if the cleanup is small enough.📝Google Testing Blog

Monday, July 20, 2026

Sunday, July 19, 2026

Saturday, July 18, 2026