Welcome to SwedenCpp

Latest blogs, videos, podcasts and releases in one stream

Thursday, July 2, 2026

If this page is useful, please consider donating a coffee

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

Friday, June 26, 2026

Pystd standard library, similar-ish functionality with a fraction of the compile timeI submitted talk proposals about Pystd, the from-scratch written standard library for C++ (custom design, not a implementation of the ISO specification) to a bunch of conferences. Unfortunately all of them were rejected, so it's blog posting time. A controversial opinion Pretty much everybody agrees that compiling C++ is slow, but I personally feel that it is intolerably slow . Other people might disagree, and that is fine, but let's look at some numbers. Compiling a helloworld executable in C takes approximately 0.02 seconds. Compiling a C++ exe that does the same thing using #include takes a second if optimizations are disabled and up to 2.3 seconds with them enabled. This is approximately a 100x slowdown. I'm using a Ryzen 7 3700X processor, so not the latest and greatest but not too shabby either. I have talked about this slowdown with some people in person and weirdly often their answers have been "that's not a problem, two seconds is insignificant". Even if you accepted this (which personally I don't) the big problem comes from scaling because the slowdown factor is approximately linear. Let's assume that in a less extreme case the slowdown was only 20x instead of 100x. In this case a program that should be done in 0.1 seconds takes 2 seconds, and therefore a program that should compile in one minute would take on the order of 20 minutes to compile. Why is compilation so slow? C++ is actually very fast to compile, the slowdowns come mostly from the way the standard library is implemented. This is actually fairly easy to test yourself by running the following shell snippet. echo '#include ' | g++ -x c++ -E - -std=c++23 | wc The -E flag tells the compiler to stop after preprocessing. The output is the source code that is fed to the compiler proper. Instead we pass it to wc and find out that merely including vector expands out to 29 000 lines of code. The number is not directly comparable to "human written code", but still, almost 30k lines of code just to get a growable array of elements seems a bit much. And vector is actually one of the lighter headers. Memory is 55 thousand lines (especially bad, since 99% of the time people just want unique_ptr), print is 65 thousand lines and filesystem is 80 thousand lines. The unfortunate reality is that if you include even a single standard library header, your compile times tank and there's nothing you can do about it. Just say no Pystd was originally just a project for me to implement low level primitives (hash maps etc) for scratch for the fun of it. Pretty quickly I came to the three design priorities: Compilation time Simplicity of implementation Performance I'm not aware of an existing standard library where build time minimization would have been a design priority. Those that are fast, like the standard libraries of C and Go, seem to mostly follow from the simplicity of their respective languages. At the time of writing building Pystd and all tests from scratch using a single core takes 4 seconds. This consists of 45 individual processes (mostly compiles, a few links). Enabling optimizations balloons the build time to 9 seconds. Using all 16 cores brings it down to 1.9 seconds. What we have thus far If we ignore test code, Pystd has 6500 lines of headers and 5600 lines of source in total. Even adding these two together yields a line count of roughly one third of std::vector 's (preprocessed) implementation. Functionality provided by Pystd includes: vector, string, validating u8string, string views, spans Hash map, ordered map (using a B-tree) sort (approximately as fast as stdlibc++), stable_sort (faster than stdlibc++) Random selection of things in the ISO algorithm header Optional, expected, variant, unique_ptr Functionality roughly equivalent to Python modules argparse, pathlib (including the ** operator), regular expressions (using pcre) and tempfile Note that not all of these are "complete" as it were. Typically they only contain the most commonly used subset of functionality. That might be a fairly small. Performance There is an earlier blog post about the performance. The numbers for converting the CapyPDF library are as follows: Compile times dropped ~80% Unstripped binary size reduced by ~75% Stripped binary size reduced by ~30% Runtime performance became ~25% faster (yes, faster, not slower) Regression can be prevented Two typical issues people raise when hearing something needs to be "fast to compile" are the following: What even is "fast"? It is highly subjective thing that depends on each person and the computer they are using. Even if something is fast now, it can not remain fast. New functionality gets added all the time, so the code is destined to become ever slower and eventually it is just as slow as the default standard library. The boring solution to both of these issues is the same: a predefined time budget. Pystd has a requirement that compiling a source file that includes any single public header must take at most 0.15 seconds. This limit was originally 0.1 seconds and it worked perfectly with GCC, but Clang's process startup time is longer than that. The test script that validates the performance is here . It must pass even on a Raspberry Pi. Interestingly the tester script was not originally single-threaded. I parallelised it only because it was the single slowest part of Pystd's compile-test cycle taking over a second. This is the requirement that all new functionality in Pystd must meet. If the code you want to add compiles too slow then either you rewrite the whole package to compile faster or you submit a patch to the upstream compiler to make it run faster. Try it yourself The code for Pystd is available in the usual places . Beginners might want to try using the sample project instead . The code works on Linux and macOS. It does not support MSVC, because the implementation uses pack indexing, which MSVC has not implemented yet.📝Nibble Stew