Welcome to SwedenCpp

Latest blogs, videos, podcasts and releases in one stream

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

If this page is useful, please consider donating a coffee

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 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

Thursday, June 25, 2026

Wednesday, June 24, 2026

Tuesday, June 23, 2026

Streamline C++ Code Intelligence Setup in Copilot CLIC++ developers can now bring IDE-style semantic intelligence into Copilot CLI with less setup. The C++ language server plugin supports richer code navigation, diagnostics, symbol understanding, and code changes by using the same build context your compiler does. That build context usually comes from a compile_commands.json file, which tells the language server how each source […] The post Streamline C++ Code Intelligence Setup in Copilot CLI appeared first on C++ Team Blog .📝C++ Team Blog
Qt Bridges: C# Bridge 0.3.0 Beta Released!Qt Bridges aim to bring Qt’s UI framework capabilities to commonly used programming languages, like C#, in a way that is familiar to developers using these languages. After the public Beta release , we've continued working on the C# bridge, adding new features and making improvements based on the feedback that we've received. Today we are announcing the release of a new Beta version 0.3.0, including some of these recent additions. Learn how to start using Qt as your next C# UI framework , try it out, and send us your feedback.📝Qt Blog
A Cross-Platform C# UI Framework via Qt’s Bridging TechnologyEvery C# UI framework comes with a familiar pattern: Windows-first, Linux absent, roadmap uncertain. WPF stalled, MAUI skipped Linux, WinUI 3 stays Windows-native. At the same time, demand for embedded Linux grows and C# teams feel the lack of good UI alternatives for C# on Linux. Qt Bridges, a bridging technology in public beta for C#, provides access to a UI framework that allows preserving your existing C# codebase while utilizing Qt Quick’s feature-rich UI libraries and APIs, hardware acceleration, and cross-platform capability.📝Qt Blog
Units Meet Linear Algebra: Two Approaches, Two ProblemsUnits Meet Linear Algebra: Two Approaches, Two Problems How do units and linear algebra fit together? We get that question often. The honest answer is that two different questions hide inside it, and they have different solutions. The occasion for answering now is concrete: mp-units ships opt-in integrations that let mainstream linear algebra libraries ( Eigen , GLM , and Blaze ) act directly as the representation type of a quantity .📝mp-units