Welcome to SwedenCpp

Latest blogs, videos, podcasts and releases in one stream

Monday, June 8, 2026

Faking keyword arguments to functions in C++One of the many nice language features in Python are keyword arguments. They make some types of APIs concise and readable. Like so: Unfortunately C does not have keyword arguments and, by extension, neither does C++. Adding them as a language feature would take 15-20 years of effort, most of which would consist of trying to convince people via email that such a feature is important and should be added. There have been attempts to implement this via macros and template magic ( link ), but they have not seen widespread usage probably because they are using macros and template magic. However it turns out that with modern language features you can fake keyword arguments fairly convincingly. Like so: The add_argument method takes a single argument which is a struct. The extra curly braces inside the parentheses boil down to "whatever the underlying argument is, construct it in place with these parameters". The dotted names are designated initializers, so those fields get the specified value whereas other fields get their default values. And there you go, keyword arguments in C++. You just have to squint a bit and pretend not to see the extra curly braces.📝Nibble Stew

If this page is useful, please consider donating a coffee

Sunday, June 7, 2026

Recent LLVM hash table improvementsLLVM has several hash tables. They used quadratic probing with in-band sentinel keys (empty, tombstone); recent work has been replacing that with linear probing with tombstone key removed. DenseMap (replacement for std::unordered_map ): DenseMapInfo::getEmptyKey() / getTombstoneKey() . DenseSet : implemented using DenseMap compiler-rt/lib/sanitizer_common/sanitizer_dense_map.h ports the implementation for sanitizers. SmallPtrSet (replacement for std::unordered_set ): hard-coded -1 (empty) and -2 (tombstone). StringMap (replacement for std::unordered_map ) StringSet : implemented using StringMap For the open-addressed DenseMap and SmallPtrSet , pointers, references, and iterators are invalidated by insert. StringMap is different: each entry lives in a heap-allocated StringMapEntry node, so entry pointers survive grow. std::unordered_map , being node-based, keeps surviving-element pointers valid across both insert and erase and only invalidates the erased element's own iterator. LLVM code rarely needs that stronger contract — callers do not hold long-lived references into the container across mutation — and that gap is what gives pass to relocating erase and bit-array occupancy. Recently, Tombstones have been removed from DenseMap and SmallPtrSet. erase() also invalidates pointers. DenseMap has also retired its empty-key sentinel, leading to significant performance improvements. DenseMap with integer keys ( int / unsigned / size_t ) had -1 / -2 reserved — a footgun, now fixed. TODO: pending patch on StringMap📝MaskRay

Saturday, June 6, 2026

Friday, June 5, 2026

I'm Allowing AI Use in my LibrariesI’ve taken the decision to allow AI use for PRs to my libraries. I personally believe these tools can be a net add (with lots of straight jackets and caveats), but I also think we’ve reached a point where I can’t really be sure whether the incoming PR requests are from people using AI tooling to help them, or just free roaming OpenClaw instances that are masking their AI nature very well, and so it feels like I’d be firmly swimming against the current as a very part-time open source contributor to try and police this. To be an open and clear about my use of AI I’ve cut pre-ai releases for all my libraries so you can get access to the code from the point before I personally started to use AI tooling (I 100% cannot confirm whether any of the contributions from others to the libraries used AI or not, but I can say with certainty that I did not use AI before these points). The pre-ai tags are: utest.h ubench.h utf8.h json.h subprocess.h hashmap.h I’ve also added a disclaimer to the README.md of each of the repositories that states: AI Usage AI tool use is explicitly permitted in commits to this repository. There is a tagged release pre-ai that denotes the last release where AI tooling was not used. And each of the PRs authored by my pi.dev agent has the footer: 🧙 Conjured by AI via pi.dev using gpt-5.5 As does each commit the AI authored too.📝Neil Henning

Thursday, June 4, 2026

Polyhedron Processing Improvements in VTKPolyhedral cells (general convex or non-convex 3D cells with arbitrary face and vertex counts) appear throughout large-scale simulation, particularly in CFD. Some solvers produce them as the dual of a tetrahedral mesh; others use them as transition cells across refinement boundaries; still others build directly on face-based polyhedral connectivity as the native primitive. Several commercial and open source CFD codes have invested in face-based arbitrary polyhedral cells as a first-class primitive, and that investment runs all the way through the pre- and post-processing pipeline because handling polyhedra well at every stage is non-trivial.📝Kitware Inc
Choosing Values for Robust Tests@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 Radion Khait A test passes. Great! But does it really mean your code is working as expected? Not necessarily.Sometimes the values you choose in your tests can create a false sense of security, especially when dealing with default values. Consider this snippet of a simple map class and its corresponding unit test: Implementation Test void MyMap::insert(int key, int value) { // Oops! The map entry is default-initialized, // the second parameter is not used. internal_map_[key]; } TEST(MyMapTest, Insert) { MyMap my_map; my_map.insert(1, 0); // This passes! EXPECT_EQ(my_map.get(1), 0); } The test passes, but the insert method is broken! It never actually stores the value. The test only passes because the default value for an integer in the map (0) happens to match the value used in the test. When choosing test values, consider the following: Test with non-default values. Explicitly test with values different from the type's default (e.g., non-zero numbers, non-empty strings, enum values other than the one at index 0). This provides greater confidence that your code is actually using the provided input. TEST(MyMapTest, Insert) { MyMap my_map; my_map.insert(1, 5); // This test would fail and reveal the bug in // the implementation above: “Expected 5, got 0”. EXPECT_EQ(my_map.get(1), 5); } Test multiple inputs that cover different scenarios, where it is reasonable to do so. Consider empty/missing/null values, numerical boundaries, and special cases that trigger complex logic. Try to cover all distinct code/logic paths. Consider using fuzzing to more thoroughly cover the input domain. Use different values for each input. This guarantees the code under test doesn't accidentally reuse a single input or switch their order. Parameterized testing can also help test a large variety of inputs with minimal code duplication. TEST(MyMapTest, Insert) { // Use a different value for `key` and `value`. my_map.insert( /*key=*/ 1, / *value=*/ 2); EXPECT_EQ(my_map.at(1), 2); }📝Google Testing Blog

Wednesday, June 3, 2026

Tuesday, June 2, 2026