Welcome to SwedenCpp

Latest blogs, videos and releases in one stream

Monday, March 9, 2026

Sunday, March 8, 2026

Saturday, March 7, 2026

Some fixes and improvements in GCCGCC 16 will probably release in a couple of months, and comes with a couple of my patches. There’s nothing too big this time, but a couple of bug fixes and some quality-of-life changes. You no longer need to explicitly pass -ftest-coverage for -fcondition-coverage and -fpath-coverage to be useful, it is now implied. The -ftest-coverage flag controls if GCC creates the .gcno files gcov needs to create the report. The coverage support in GCC is built on top of arc profiling which underpins profile guided optimization (PGO), and the PGO doesn’t need the .gcno, only the .gcda (counters). Coverage was a sort of side effect, and MC/DC and prime path coverage was built on that framework. Unlike arc profiling, it doesn’t make much sense to ask for MC/DC and prime path coverage without also wanting to read the reports, so this makes GCC a bit easier to use. I fixed a bug where gcov-dump printed the wrong offset for condition blocks, and taught it how to print the PATHS tag. gcov-dump is mostly useful for developing gcov itself, but it’s nice that it’s there. There’s a another bugfix in there too, which caused bad counter updates, but this bug was never included in a release. I have revised my paper on MC/DC , collected some data for it; on how the instrumentation affects compile time, runtime overhead, and object size. What I found was that compile times suffered greatly when analyzing expressions with many conditions joined by a single operator. A phase of the CFG analysis is figuring out which other conditions to mask when we take an edge, and this step evaluated all possible candidates. What I realised is that we don’t need to evaluate all of them, the search starting at the left-adjacent operand (which we must also include) will dominate and always find all the masked conditions. This had a massive impact on compile times. This is one of those problems that don’t really show up in testing that easily, because under normal circumstances this isn’t a problem. I wrote a small test program which causes the worst behaviour, a single (x && y && ... && z) . I tested two cases, 1 is (x && y && ... && z) and 4 is (x1 || ... || x8) && ... . These are the compile times before and after the fix: Those numbers are for all of GCC, including parsing, code generation, and linking. I also measured just the MC/DC analysis pass (finding the masking table and emit the instrumentation code), and get somewhere between 15–20 times speedup, not bad at all. As it turns out, algorithms matter. before: 20822.303 ms (41.645 ms per expression) after: 1288.548 ms ( 2.577 ms per expression) As you can see from the graphs, the performance hit really starts to kick in past 16 conditions, which is quite rare in practice. Still, faster is nice. I did find one case with 27 conditions in GNU ls, but that’s very much the exception.📝patch – Blog

Friday, March 6, 2026

Thursday, March 5, 2026

Beyond Affine: Thin Plate Splines for Serial Histology AlignmentWhen Your Images Don’t Quite Line Up If you work with serial histology slides, you are familiar with the routine: Zoom into a perivascular region. Toggle to the adjacent stain. Pan. Nudge. Recenter. Repeat. Serial sections are routinely used for cross-stain interrogation and volumetric reconstruction. But consecutive sections from the same tissue block rarely align well enough for direct comparison, especially at high magnification. Sections may be skipped, and tissue deforms during cutting and mounting in ways that undermine direct spatial correspondence. Those distortions may seem small, but repeated hundreds of times a day, they compound. Misalignment undermines comparative analysis, annotation quality, and downstream machine learning workflows. At first glance, this seems like a straightforward fitting problem that a simple affine transform should be able to handle. But, once applied, this is clearly insufficient.📝Kitware Inc

Wednesday, March 4, 2026

Tuesday, March 3, 2026

Accessing inactive union members through char: the aliasing rule you didn't know aboutI recently published an article on a new C++26 standard library facility, std::is_within_lifetime. As one of my readers, Andrey, pointed out, one of the examples contains code that seems like undefined behavior. But it’s also taken — almost directly — from the original proposal, so it’s probably not UB. And that’s correct, it’s not undefined behavior. Let’s first examine the example and the UB...📝Sandor Dargo's Blog
Set Safe Defaults for Flags@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 Zhe Lu We all make mistakes. But big mistakes can cause big headaches! Suppose you're writing a utility to update production data for a launch. Before making changes to production data, you want to perform a dry run to validate the expected changes. In your excitement, you forget to include the --dry_run flag in your command: $ /scripts/credit_accounts --amount=USD10 # Oops, I forgot to include --dry_run You realize your mistake too late. Safe flag defaults can prevent a simple mistake from turning into a major outage: Flag has unsafe default: cliArgs.addBoolFlag(name="dry_run", default= False , help="If set, print change summary, but do NOT change data.") Flag has safe default: cliArgs.addBoolFlag(name="dry_run", default= True , help="If set, print change summary, but do NOT change data.") Safety depends on context: When defining flags, choose the default that minimizes the cost of potential mistakes . This might involve defaulting to a "dry" run, asking for user confirmation before irreversible actions, requiring a confirmation flag on the command line, or other strategies. If you’re writing documentation that contains commands, always set values to minimize the damage if run blindly: Flag in documentation has unsafe default: ## How to commit changes Use this command to commit changes. Use --dry_run to test and compute and report changes. ```shell /scripts/credit_accounts --amount=[value] --filter=[conditions] ``` Flag in documentation has safe default: ## How to commit changes Use this command to compute and report changes. Use --nodry_run to commit the changes. ```shell /scripts/credit_accounts --amount=[value] --filter=[conditions] ``` Similarly, consider requiring that environment-specific flags (e.g., backend addresses and output folders) be explicitly set . In this situation, unspecified environment flags will crash your program, instead of potentially mixing configuration across environments.📝Google Testing Blog

Monday, March 2, 2026

A dialogue on trivial-abi and trivially relocatableI wrote in ["`[[trivial_abi]]` 101"](/blog/2018/05/02/trivial-abi-101/) (May 2018), during the active development of the `[[clang::trivial_abi]]` attribute: > Relation to trivial relocatability: None... well, some? > > As you can see, there is no requirement that a `[[trivial_abi]]` class type > should have any particular semantics for its move constructor, its destructor, > or its default constructor. Any given class type will _likely_ be trivially > relocatable, simply because most class types are trivially relocatable by accident... A correspondent writes in with a query for Socrates (previously seen on this blog [in July 2023](/blog/2023/07/16/why-span-has-no-resize/)). _Epistolographos writes:_ Actually, I think trivial-abi-ness and trivial relocatability are almost the same thing.📝Arthur O’Dwyer

Sunday, March 1, 2026

Saturday, February 28, 2026