Welcome to SwedenCpp

Latest blogs, videos, podcasts and releases in one stream

Friday, July 3, 2026

If this page is useful, please consider donating a coffee

Thursday, July 2, 2026

Wednesday, July 1, 2026

A Cross-Platform Rust UI Framework via Qt’s Bridging TechnologyRust has achieved something extraordinary: it genuinely excites people to write software. But when it comes to building a real user interface, the ecosystem is still finding its footing. There are numerous options to pick your Rust UI framework from, including those gaining traction, like Iced and egui. Most of the available UI frameworks, however, are still establishing themselves in production environments and fall short in feature-richness. Qt Bridges, a bridging technology in public beta for Rust, brings something different to the table: over three decades of real-world use, commercial support, and a framework that already runs in automotive dashboards, medical devices, and industrial systems worldwide. Qt Bridge for Rust makes that maturity available to Rust developers, providing access to a UI framework that lets you keep your Rust codebase while using Qt Quick’s feature-rich UI libraries and APIs, hardware acceleration, and genuine cross-platform support.📝Qt Blog
Improving Embedded Software Quality With Parasoft C/C++test, CLion, and AIEmbedded software development comes with a unique set of pressures: strict safety and security standards, complex toolchains, and the constant challenge of catching defects as early as possible. Starting with CLion 2026.1.2, you can open SARIF findings from Parasoft C/C++test analyses for standards such as MISRA C/C++, AUTOSAR C++14, CERT C/C++, and CWE directly in […]📝CLion : A Cross-Platform IDE for C and C++ | The JetBrains Blog
Some recent discoveriesFirst images of PHerc. 1667. When Vesuvius buried Herculaneum, it turned many papyrus scrolls in the Villa dei Papiri to burnt hunks of carbon without destroying their physical structure. Since the 2010s (or earlier?), people have tried to non-invasively image what remains of the scrolls. In June 2026, the latest “Vesuvius Challenge” prize was awarded to a team who successfully imaged the first “complete” scroll. The team’s report (“Complete virtual unwrapping and reading of a rolled Herculaneum papyrus”, Angelotti et al., 2026) points out that the scroll is even less “complete” than it used to be: invasive efforts in the late 20th century had already reduced it from about 14 grams of carbonized gunk to about 6 grams. The group’s full transcription consists of only 300 to 400 complete words. They identify PHerc. 1667 as some sort of philosophical treatise — unsurprising, as many of the scrolls that could already be deciphered turned out to be works of Philodemus. Contrary to some media reports, the title of PHerc. 1667’s work is unknown; but a separate finding reported in the same paper identifies PHerc. 139 as book 8 of Philodemus’s On gods (περὶ θεῶν, book Η).📝Arthur O’Dwyer
Hub is hereDuring Q2 2026, I’ve been working in the following areas: boost::container::hub The Boost official review took place April 16-26. The library was accepted as part of Boost.Container. Many thanks to the review manager, Ion Gaztañaga, and all the people who participated: Arnaud Becheler, Matt Bentley, Matt Borland, Dominique Devienne, Peter Dimov, Emil Dotchevski, Alexander Grund, Andrzej Krzemieński, Christian Mazakas, Peter Turcan. During April-June I implemented the feedback received (PR#20), and after that Ion took over and migrated the code and documentation to Boost.Container (adding some interesting performance improvements that I helped a bit with). boost::container::hub will be released in Boost 1.92 (August 2026), after which the original repo will be deprecated or removed. Boost.Unordered Added interoperability with C++20 ranges to all the containers in the library (PR#355). Reviewed and merged PR#348 from Daniel Král (performance issue with closed-addressing containers when rehashing at very large container sizes). Written maintenance fixes PR#346, PR#351, PR#352, PR#353, PR#354. Addressed documentation issues #349, #350. Boost.MultiIndex Fancy pointer support has been extended so that multi_index_container iterators now store references to the elements through the allocator’s pointer type (PR#100). In particular, this means that iterators can now be placed in shared memory using Boost.Interprocess allocators. Reviewed and merged PR#94 from Daniel Král (performance issue when rehashing at very large container sizes). Reviewed and merged PR#98 from Jonathan Wakely. Written maintenance fixes PR#97, PR#99. Boost.ICL As discussed in a previous entry, recent changes in libc++ v22 broke this library. These changes are related to the fact that non-heterogeneous lookup for associative containers is poorly specified in the C++ standard. I filed a LWG issue and defended a resolution with the LEWG that was consistent with the original semantic assumptions of Boost.ICL, but this resolution was not accepted (Brno, May 10). There was a fix on hold (PR#54) pending acceptance from ICL’s maintainer, but he’s been unavailable and in the end I requested write permission to the repo and merged the PR so that it makes it in time for Boost 1.92. The PR includes some additional fixes not related to the core issue. Boost.Bloom Reviewed and merged PR#46 from Jonathan Wakely. Written maintenance fix PR#47. Boost.Graph I had the honor to participate remotely in the Boost.Graph Workshop held in Paris, May 6, where I presented some simple ideas towards modernization of BGL API. Support to the community I’ve been helping a bit with Mark Cooper’s very successful Boost Blueprint series on X. Supporting the community as a member of the Fiscal Sponsorship Committee (FSC).📝The C++ Alliance

Tuesday, June 30, 2026

Introducing the Coco MCP Server PreviewAuthors: Otso Virtanen and James Vance The Context Problem in Test Case Generation Generating tests is one of the most common practical use cases for AI coding agents. However, without runtime code coverage data, an AI coding agent reasoning about test gaps must statically analyze source files and test files to infer what is likely covered. This is unreliable: the agent cannot distinguish between a function that is called indirectly through several layers and one that is never reached, nor can it detect dead code reliably.📝Qt Blog

Monday, June 29, 2026

Why a Quantity Has a CharacterWhy a Quantity Has a Character A few years ago at CppCon, an engineer who works with electrical power systems every day stopped me after a talk. He told me that his team confuses active power , reactive power , apparent power , and complex power all the time, and that the mistake is easy to make and expensive to find. Then he said the sentence that has stuck with me since: a units library that will not make those four incompatible types is of no use in his industry. He is right. And he is not alone.📝mp-units

Sunday, June 28, 2026

Optimizing LLVM's bump allocatorBumpPtrAllocator is LLVM's bump allocator (arena allocator): each allocation bumps a pointer within a slab, and everything is freed at once when the allocator dies. It backs Clang's ASTContext , lld's make object pools, TableGen records, and many other arenas. Here is the fast path before three recent changes: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 __attribute__((returns_nonnull)) void * Allocate ( size_t Size, Align Alignment) { BytesAllocated += Size; // (3) accounting RMW uintptr_t AlignedPtr = alignAddr (CurPtr, Alignment); // (1) always realign size_t SizeToAllocate = Size; # if LLVM_ADDRESS_SANITIZER_BUILD SizeToAllocate += RedZoneSize; # endif uintptr_t AllocEndPtr = AlignedPtr + SizeToAllocate; if ( LLVM_LIKELY (AllocEndPtr uintptr_t (End) && CurPtr != nullptr )) { // (2) bound + null check CurPtr = reinterpret_cast char *>(AllocEndPtr); ... return reinterpret_cast char *>(AlignedPtr); } return AllocateSlow (Size, SizeToAllocate, Alignment); }📝MaskRay

Saturday, June 27, 2026

A deep dive into SmallVector::push_backtl;dr This blog post describes a recent SmallVector::push_back optimization for approximately trivially copyable element types. SmallVector is LLVM's most-used container, and push_back its hot operation. For the trivially-copyable specialization the fast path should be fast. 1 2 3 # include void f (llvm::SmallVectorImpl int > &v, int x) { v. push_back (x); } clang -S --target=x86_64 -O2 -DNDEBUG a.cc generates: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 push rbp # callee-saved spills + a stack realignment, push rbx # all on the fast path push rax mov eax, [rdi + 8] # size cmp eax, [rdi + 12] # vs capacity jae .Lgrow .Lstore: # reached from the fast path AND from .Lgrow mov rcx, [rdi] mov [rcx + rax*4], esi inc dword ptr [rdi + 8] add rsp, 8 pop rbx pop rbp ret .Lgrow: mov rbx, rdi # keep `this`/`x` alive across the call mov ebp, esi call SmallVectorBase ::grow_pod ... jmp .Lstore📝MaskRay